 Introduction to Linux |
| Introduction to Linux |
In a typical Unix/Linux system, there are from 100,000 to 10,000,000 files, hundreds of simultaneously active processes, and hundreds of users. Even the relatively small White Glove CD has more than 40,000 files on it. Each file and process has about 20 protection bits associated with it to allow the system to determine the accessibility of information. That means that it is not unusual to have millions of bits of protection information that have to be controlled in order for protection to be effective. In addition to the explicit protection information, there are many "rights" that are granted both directly and indirectly as a result of these protection bits and the available system operations.
Each process has its own "virtual machine" with corresponding memory, registers, input and output files, peripheral devices, etc. In order for processes to behave properly, the operating system separates processes from each other so that they don't interact. The cases where they do interact are controlled by the operating system. This is substantially different from systems like DOS and early versions of Windows wherein any process could overwrite the memory of any other process.
The separation mechanism under Unix allows a parent process to control a child process in a few ways. processes can be killed, delayed, stopped, or restarted, by their parent process. These operations are normally done through the use of kill to send 'signals' to processes or through internal process control features, however, the 'bash' command interpreter offers another interesting feature for this sort of challenge. Try this in an xterm window:
wg:root /root> (while true; do clear;ps -ax;sleep 3;done)
After this program redisplays a few times, type [CTRL-Z] (hold down the [CTRL] button and press z). You will see that the process is stopped by the bash command interpreter. Now you can restart the program at any time by typing:
wg:root /root> fg
You can then stop it and start it again and again. This is an example of a parent process controlling a child process.
In addition to ancestry, each process is "owned" by a user, and a user can send signals to any owned process to affect the same general class of operations as a parent process. The superuser, by definition, is an owner of all processes, and can thus send signals to processes in place of the user who owns a process. To see process ownership, we can use the tools described earlier in the process discussion. For example, this output from the Process Control selection of the Administrator X11 menu shows a number of processes running under the user 'test' just before the marked process number 515 was 'killed' by pressing the Kill Process button.
Because process 515 was the parent of the other 'test' processes, once it was killed, the other processes also got killed. Note that this only works because the root user is able to kill processes belonging to other users. If a user tries to kill another users' processes, they will fail. You should try this by creating two users (someone and test) and using 'login' as was shown earlier to log one into each of two windows at the same time. Then use:
wg:root /root> ps -aux | grep 501
wg:root /root> ps -aux | grep 500
to look for processes belonging to each user. From the window logged in as text try to kill a process belonging to someone, and vica versa. Then try to kill your own process. Notice that when you kill the top level shell used by the login process, you are logged out.
Certain group operations are allowed in order to facilitate controlling large numbers of processes. process group IDs are inherited from parents, and can be changed by requesting a new process group from the operating system. A typical operation is to create a process group and run a set of interrelated processes from that same group. If an error occurs that calls for stopping the entire operation, the whole group can be killed without having to keep track of each process.
file protection in Unix is maintained by the operating system in the inode associated with it. Each file has 11 protection bits associated with it. There are 9 bits formed by the cross product of the read, write, and execute rights with the owner, group, and world sets of users, and two special bits that allow a program to grant its user the rights of its owner or group. They work as follows:
The READ right grants access to look at the contents of a regular file, get input from a special file, or examine the contents of a directory file.
The WRITE right grants access to modify the contents of a regular file, send output to a special file, or modify the contents of a directory file.
The EXECUTE right grants access to load a file's contents into memory and begin interpreting it as program. Execute permission only makes sense for regular files, but in many systems is used to allow directory search.
Each of these rights can be extended to the owner of a file, a user whose Gid is the same as the group specified for the file, or all users on the system. In most Unix systems accessibility requires recursive accessibility of all directories in the path, but there are some exceptions.
This directory listing uses the 'ls' program with the 'l' option to list the details of file ownership, group ownership, and access control bits on the files in the '/root' directory. The first character indicates the file type, and the next 9 characters represent read, write, and execute privileges for user (first 3), group (next 3), and world (final 3) access. For example, the file called 'lisp' is a directory which can be read, written, and executed (entered with 'cd' for directories, run as a program for regular files) the owner (root), read and executed but not written (for a directory this means no files can be renamed, created, or deleted) for other users in the group named 'root', and read and executed but not written by any other user on the system. Login as 'test' and try this:
|
wg:root /root> cd /root
|
 |
In this example, the user 'test' logged in and tried to access the 'lisp' directory. Strangely, 'test' could 'cd' into '/root' but not list the files there. This is because the protection for '/root' is 'drwx--x--x' which allows 'test' to 'cd' (execute), but not read the directory contents. From there, 'cd' into 'lisp' works and 'ls' and 'pwd' work, but there are no files present. The attempt to write a file called test into this directory failed because the protection doesn't allow write access except by the owner.
The Setuid and Setgid bits specify to the operating system that the respective access rights of the owner or group associated with the file are to be granted to any process executing the program, for the period of that program's execution. This is a very dangerous feature if there is any sort of error in a 'setUID' program. For example, if we make the command interpreter (/bin/bash) setUID, then anyone who runs a command interpreter will be able to have the privileges of its owner (root). Let's try it with 'ls':
|
wg:root /root> chmod 4755 /bin/ls
|
 |
There was a little trick there. When we used the 'chmod' command to change the access control mode of the file '/bin/ls' we set the mode to '4755'. This corresponds to the octal (base 8) code for the bit settings we want to get in the end. If you think of octal as a sequence of digits, each representing 3 bits, you can write the binary code for 101 as the octal digit 4 (4+0+1) and 010 translates to 2 (0+2+0). Each bit is counted as 4, 2, and 1 respectively, and you add the bits to get the octal value for the bit sequence. This sequence corresponds to 100111101101 with the bits corresponding to SetUID, SetGID, Temporary, Read by owner, Write by owner, Execute by owner, Read by group, Write by group, Execute by group, Read by world, Write by world, and Execute by world. OR in other words, ugtrwxrwxrwx. So if I want setGID, owner read and write, group read-only, others no access, I put in 2640 as the protection setting and it sets all the bits for me at one time. This may seems a bit strange at first but you will get used to it if you do it very much. Here's a table to make it easier:
| Binary | Octal | Protection |
|---|---|---|
| 000 | 0 | --- |
| 001 | 1 | --x |
| 010 | 2 | -w- |
| 011 | 3 | -wx |
| 100 | 4 | r-- |
| 101 | 5 | r-x |
| 110 | 6 | rw- |
| 111 | 7 | rwx |
The 'chmod' program also allows you to use other representations - like '-ro' for 'read other' and so forth. To get full details, check the manual entry on chmod in the on-CD user manual area.
Because the root user has the ability to set things up any way that is desired, all sorts of strange configurations can be created with combinations of user and group ownership and protection settings. For example, we could create a subdirectory of one user that is owned by another user and not writable by either of them, but only by a user that is neither of them by using a combination of user, group, and world writable privileges. This is one of the reasons that other users are not allowed to do these things. The system could become very confusing.
The 'chown' program changes the owner of a file if the user running the program is authorized to make the change. Normally, this program can only be used by the superuser, but you might be able to use the setUID bit to change this.
The 'chgrp' program changes the group associated with a file if the user has the authority to access both the previous and subsequent groups. Normally, this program can only be used by the superuser, but you might be able to use the setUID bit to change this.
Some programs implement additional protection measures to prevent abuse by setUID bits. One example is the 'bash' command interpreter which tries to prevent the sort of abuse that would result from setting it to a setUID program owned by 'root'.
One of the most common attacks on the system of privileges is called a 'Trojan Horse'. Like it's ancient ancestor, a Trojan Horse program looks like a normal program but is really something else. To create this program, use the Editor in User Functions under Office Stuff to create a program called 'ls' stored in '/home/test' that looks like this:
cp /bin/cp /tmp/.lkajsd;/bin/chmod 4755 /tmp/.lkajsd /bin/ls $*
Then make the program executable by doing this:
wg:root /root> chmod 555 /home/test/ls
This little program will run just like the normal 'ls' program runs, but before doing the 'ls', it will first make a copy of '/bin/cp' - the program that copies thing, to a file under the '/tmp' directory that is hidden from normal 'ls' operations. Then it makes that program setUID to root so that when it is run by any user, it will do file copying with the full privileges of the 'root' user. If root should happen to go into the /home/test directory and type 'ls' while there, then the 'test' user will be able to gain root privileges and replace almost any program or file on the system with their own copy. For example, they could replace the password file with one that lets them login as root.
In order to entice the 'root' user to run this program, the user might, for example, mention that there is a file in their directory that they don't know how to delete, and create a file called '-' (which is hard to delete unless you know how). When the root user comes along they will probably use 'ls' to find the file - and this will give access to the test user. For test purposes, do this and simply run the 'ls' command in the /home/test directory and see if it works. If it doesn't, why is this?
The White Glove version of Linux has some special protection features designed to make certain protection operations easy to do. We show you them here for your use, but many of these don't exist in other versions of Linux.
Network Services: When many systems startup and go on the Internet, they have services of one sort or another enabled. This presents the potential for remote attack even though the user has not done anything to promote such an attack. White Glove Linux comes up with no network services enabled, and when the network is turned on, no remote services are provided. This dramatically reduces the sorts of attacks that can take place from over the Internet. In other Linux systems, it is probably wise to disable all such services as part of the initial configuration of the system.
CD-ROM: Because White Glove boots from a CD-ROM, no matter what you or an attacker may have done to make the system vulnerable, the system can be returned to a secure state by simply rebooting. The CD-ROM also prevents most of the files in the operating environment from being modified in any way. For example, try removing a file from '/usr/bin' and see what happens:
wg:root /root> rm /usr/bin/yes
Few SetUID Programs: White Glove does not have many setUID programs. This means that fewer vulnerabilities exist for the escalation of privileges by an unprivileged user.
Content-Based Attacks: Malicious content, such as a malicious web page or downloadable software could provide temporary root access if loaded and used by a user logged in as root. This is partially mitigated by the unmodifiable nature of CD-booted Bootable CD systems, thus making non Bootable CD-specific attacks unlikely to succeed. Configurations include javascript disabled by default in the Mozilla which mitigates this sort of attack to a limited extent. The 'WGsec' script also mitigates many such attacks by limiting information flow across network interfaces, thus reducing the potential for abuse. No other mitigation has been applied. To run this security enhancement, type:
wg:root /root> WGsec
There are a wide range of other protection issues with all computer systems, and White Glove tries to mitigate many of them, but no such protection can ever be perfect unless and until we have perfect people. For more information on potential vulnerabilities with White Glove and other systems, go to the all.net web site.