|
Inconvenient and Unreasonable Console Constraints
Any user with physical access to a computer generally has the ability to trivially override any system security. This is certainly true on most Linux systems by default; unless BIOS passwords are set and the case is securely locked, anyone with physical access to the machine can break in regardless of the operating system in use. Proper use of passwords just makes entry a little harder.
Linux (by default) places some limitations on what a user with physical access to the machine can do, despite the general lack of absolute security. This is good, in that it protects users from their mistakes. However, it is annoying when it makes it difficult for users with physical access to do things that they expect to be able to do, such as read from and write to floppy drives, access sound hardware, and so forth.
Users have surmounted this problem in the past in a few ways:
- Use the su command to assume superuser status in order to temporarily override system permission limitations (su -c 'tar xf /dev/fd0').
- Allow one particular user or group to access system devices regardless of whether that user or group is physically at the system console at the time (chown jim /dev/fd0).
- Allow everyone on the system to use system devices (chmod 666 /dev/fd0).
These are not really solutions; they are essentially work-arounds. The need to use any of the work-arounds makes Linux a less desirable operating system for nearly any user, but especially for users who look at that list and do not have the foggiest idea how they would go about doing any one of the three work-arounds, or what the example command lines given in parentheses mean.
An additional problem has been running commands that only the superuser can run. One problem in particular is the shutdown command which allows the user to shut the computer down correctly. While shutdown is invoked by pressing the control-alt-delete key combination at a text console, it does not work from within X, and so users who have no way of knowing better may simply turn their systems off without a proper shutdown.
Inconvenient X Security Mechanisms
The other end of the spectrum has been X access. X has often been set up in a rather insecure mode where anyone on an accessible network can quietly "sniff" keystrokes and thus learn users' passwords without their knowledge. Unfortunately, protecting against this has caused inconvenience. Red Hat Linux has, in the past, come configured with a compromise that makes machines relatively secure but occasionally difficult to use.
The difficult-to-use part occurs when you use the su command to assume the privileges of another user account—and discover that as that user you are unable to run X-based applications. You have just fallen victim to security. Unless you have heard of (and know how to use) the xauth or xhost commands, you will have difficulty getting around the problem.
On the other hand, that problem is a smaller price to pay than the alternative, which is having untrustworthy users stealing passwords and other secrets as you type them. Not everyone is on a network with untrustworthy users, but those who are appreciate the security.
Many users frustrated by X inaccessibility have just blindly typed the command
xhost +
that some kind friend told them solves the problem. Unfortunately, this command entirely disables all X security. It will not hurt on a stand-alone, single-user, non-networked computer; but such setups are becoming increasingly rare. If, for example, you have a PPP connection, or an ADSL connection, or a cable modem connection, you want X security mechanisms in place.
|
