These classnotes are depreciated. As of 2005, I no longer teach the classes. Notes will remain online for legacy purposes

UNIX03/Permission Problems

Classnotes | UNIX03 | RecentChanges | Preferences

Recognize that any file (including directory or device) that has any permission available to a potential cracker might weaken your system's security. Linux is based on Unix, which as developed before most systems were on the internet. As such, many system files are readable by everyone and some are even writable.

umask

The umask utility sets the file mode creation mask of the current shell execution environment to the value specified by the mask operand. This mask affects the initial value of the file permission bits of subsequently created files.

 umask: usage: umask [-p] [-S] [mode]

umask can be added to users startup scripts to enforce file creation without world read rights. Something such as

 umask 022
or
 umask 027

is typically advised. Typing umask without any arguments shows what your current umask is. root's umask should always be 022.

Directories and the Sticky Bit

Very few files should have world write access. Among those that should are your tmp directories with mode 1777 (typically /tmp and either /var/tmp or /usr/tmp). As you recall, if someone has write access to a directory, Linux will allow them to create new files in that directory, remove existing files, or move files info, out of, or within that directory.

The problem arises when a malicious user on the system uses this functionality to intercept and manipulate data from another user created this way.

For example, imagine a web-browser that stores it's temporary files in /tmp. A malicious user could snatch passwords, credit card numbers, browsing histories, etc. if they new what they were doing. As another example, imagine an e-mail client that uses /tmp to store its messages as they are being composed. A malicious user could hijack a message as its being composed or preparing to mail and place their own alternate message. Even worse, some authentication programs use /tmp to store files, and the user could intercept and modify some of these, gaining even more access to the system.

This problem is not as big as one might think, as using umask a system administrator can restrict the permissions of a file a user's application can create.

The solution to the dilemma was to use something called the sticky bit, octal 1000. In Linux (and most Unix systems), if a directory has the sticky bit on, the kernel will not allow someone to remove or rename files in that directory that they do not own even if the directory's write bit permission would allow otherwise.

The point is that directories where different users each need to be able to create files but should not be able to remove eachother's files should have the sticky bit set. For example, /tmp might have its permissions correctly set via

 # chmod 1777 /tmp

Finding Permission Problems

The following command will search for world writable files and dump a list of them to a file

 # find / ! -fstype proc -perm -2 ! -type l -ls 2>&1 > world

you can alternatively have this list mailed to you

 # find / ! -fstype proc -perm -2 ! -type l -ls 2>&1 | \
   Mail -s 'world writable' your_address@someplace.com

Note that many of them will be /dev files. And many of these must be world writable (such as /dev/null).



Classnotes | UNIX03 | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited May 31, 2003 3:00 am (diff)
Search:
(C) Copyright 2003 Samuel Hart
Creative Commons License
This work is licensed under a Creative Commons License.