December 03, 2004 Edition

By Jorge "whiprush" Castro (, Amit "Prototyped" Gurdasani (


Kernel vulnerability leads to compromised Debian servers

Lately, there's been a spate of cracked servers running Debian. The issue was traced ( to a kernel vulnerability involving unchecked parameters in the do_brk C function that is part of the kernel's virtual memory manager. The vulnerability is a privilege elevation ( one that can allow local users to gain root privileges on affected machines. The issue was discovered and a small patch was produced in the last weeks of September, but this was deemed to be too late for incorporation into the 2.4.22 release.

Linux kernels 2.4.23 (released a few days ago) and 2.6.0-test6 and newer incorporate the patch, as do updated Debian (, Red Hat (, Mandrake (, Trustix ( and Slackware ( kernels. Other distributions are sure to follow; announcements usually show up on the BugTraq ( mailing list. More information ( is available for folks who are interested, as well as the Debian Investigation Report (


Linux.Ars Holiday Shopping Guide

Christmas is coming up and the shopping madness has started, so we will, in the spirit of Mac.Ars and the new System Guide, give you some gift ideas for the penguin lover(s) in your life. We would like to thank the Linux Kung Fu forum readers for helping us come up with the suggestions in this thread (

Making that Linux geek's day on the cheap (under US$50)

Revolution OS (, the documentary on the rise of Linux, GNU, the GPL, Open Source and related themes, on a CSS and region-code free DVD. It's worth a watch. (Hey, you get to see Richard Stallman evangelize about Free Software! Thankfully, that's nowhere near the highlight of the video.)

Debian swirly stickers ( for those Debian users you know. The stickers are really cheap to gift, and there's special entertainment in watching the receiver go berserk sticking them on everything he sees.

Even though he might not be a Pulitzer Prize winning author, Linus' book Just for Fun: The Story of an Accidental Revolutionaryis ( still a pretty good read, and it says a lot about his character, the history of Linux, and that Linus is actually just a regular guy.

"And Ari Lemke, who insured that is made its way to the ftp site, hated the name Freax, He preferred the other working name I was using — Linux — and named my posting: pub/OS/Linux. I admit that I didn't put up much of a fight. But it was his doing. So I can honestly say I wasn't egotistical, or half-honestly say I wasn't egotistical. But I though, okay, that's a good name, and I can always blame someone else for it, which I'm doing now."

The Business and Economics of Linux and Open Source ( is a fitting gift for someone interested in the business possibilities surrounding Linux and Open Source software.

For those who are hungry for knowledge, a book from O'Reilly Associates ( is seldom a poor choice.

A stuffed Tux doll ( is almost always a nice little gift to put on top of monitors or mantelpieces.

For those Linux users that still need to run Windows software from time to time, a subscription to Transgaming's WineX ( or a copy of Crossover Office ( or the Crossover Plugin ( would make their live a bit easier.

Personally imprinted Linux penguin stress-busters ( Cute and fun.

Other inexpensive gift ideas, such as T-shirts, can be found on the merchandise page of most big software project and the major Open Source advocacy groups.

For more discriminating tastes (US$50-150)

TheModel M remade ( It's among the more loved and sought-after keyboard models ever, and it's available again. Thanks to its robustness, not only does it give a solid feel and excellent feedback to the user, it may also find use as a club in a post-apocalyptic wasteland.

Or get someone a Happy Hacking keyboard (, and have him never complain about useless keys that get in the way again.

For the geek who has (nearly) everything (US$150 and over)

If you have a bit of money to burn on a Linux geek, get them a Sharp Zaurus, the premiere Linux PDA.

The SL-5500 ( At US$250-350, the low-end Zaurus is already an impressive PDA with high usability. Due to its built-in Compact Flash and Secure Digital card slot, it is remarkably expandable, and one of the most powerful PDAs in its price range.

A step above it is the SL-5600 (, which features a higher resolution screen. Both have a 16-bit color display and a pull-out keyboard.

The SL-C760 ( is the high-end Zaurus with an impressive VGA display which can either be used in clamshell mode with a full keyboard, or be swiveled and rotated into portrait mode, in which it acts like any other stylus-based PDA.


TTT: Tools, Tips and Tweaks

In this issue, we introduce access controls on files and directories in UNIX.

Filesystem permissions — Why your disgruntled co-worker couldn't plant that evidence

Every multiuser platform worth using has the ability to let owners of files and directories decide who gets to access their files and to what level. In UNIX, this is traditionally accomplished by the use of permission bits accompanied by ownership information.

Every file and directory is owned by a system user and a group of users, of which the owning user may or may not be a member. The owning user has a set of rights (that he can modify), the owning group has its own set of rights (that it cannot modify), and the rest of the users have a separate set of rights.

The primary permissions available are read, write and execute permissions. (Directories with an execute permission set will allow the users concerned to traverse, or see into, them.) There are usually twelve permission bits available. Nine of these are the three sets of read, write and execute bits as mentioned earlier. We'll get into the remaining three later on.

umask: Governing file creation

When a file is created, the permissions are determined by the umask. This is a user setting that sets what permissions are not to be set. This is usually expressed in the base-8 numbering system, octal, to represent the bits. Here's what the twelve bits look like, written from most significant (highest-value digit) to least significant (lowest-value digit):

tSs  rwx  rwx  rwx
misc user grp  other

Each bit is 1 if the permission is granted, or 0 otherwise. An octal digit, ranging from zero to seven, represents exactly three bits' worth of information, so a single octal digit is able to describe completely the miscellaneous, owning user's, owning group's and other users' permissions. Here's what the rwx octal digits mean:

Octal digit    Permissions
0              none
1              execute/traverse
2              write
3              write and execute/traverse
4              read
5              read and execute/traverse
6              read and write
7              read, write and execute/traverse

If you sense a pattern here, you're right: the reading permission has an octal value of 4, the writing permission has an octal value of 2, and the execute/traverse permission has an octal value of 1. Add them together appropriately to come up with the combined permissions.

Coming back to the file creation mask, or umask, it turns off permissions. For instance, if we set the umask to 0, the files created are readable and writable by everyone, since the default behavior is to give read and write permissions to all users, and the zero umask won't turn any permissions off.

$ umask 0
$ touch shovel
$ ls -l shovel
-rw-rw-rw-    1 amitg    amitg           0 2003-12-03 05:24 shovel

This indicates that the file shovel is owned by the user amitg and the group amitg, and is readable and writable by all users. Now if we wanted to make sure that any file we created could not be written by the owning group, and could not be read, written or executed by anyone else, we can create a umask to accomplish this. First, we note that the owning group must never have the write permission, 2, and others must never have read (4), write (2) or execute (1) permissions, so the digit corresponding to others' permissions should be a 7 in our umask. Putting these together, we get 027.

$ rm shovel $ umask 027 $ touch shovel $ ls -l shovel -rw-r----- 
      1 amitg amitg 0 2003-12-03 05:29 shovel 

Presto — just as we wanted.

chown and chgrp: Modifying ownership

We modify ownership using the chown and chgrp commands. Typically, only the superuser can use them; otherwise, any user could plant files as though they were owned by someone else. As we'll see shortly, this would lead to major security issues.

# ls -l shovel
-rw-r-----    1 amitg    amitg           0 Dec  3 05:29 shovel
# chown default shovel
# ls -l shovel
-rw-r-----    1 default  amitg           0 Dec  3 05:29 shovel
# chgrp tty shovel
# ls -l shovel    
-rw-r-----    1 default  tty             0 Dec  3 05:29 shovel
# chown amitg.dialout shovel
# ls -l shovel              
-rw-r-----    1 amitg    dialout         0s Dec  3 05:29 shovel
# mkdir -p p/q
# ls -ld p p/q
drwx------    3 root     root         4096 Dec  3 05:33 p/
drwx------    2 root     root         4096 Dec  3 05:33 p/q/
# chown -R amitg.dialout p
# ls -ld p p/q            
drwx------    3 amitg    dialout      4096 Dec  3 05:33 p/
drwx------    2 amitg    dialout      4096 Dec  3 05:33 p/q/

Note that at least with GNU chown and chgrp, the -R option causes all files and directories under the specified directory to also acquire the ownership specified.

chmod: Modifying permissions

What if we want to change the permissions on a file? We use the handy chmod command. This has two syntax forms. There's a symbolic syntax that looks like this:

$ ls -l shovel
-rw-r-----    1 amitg    amitg           0 2003-12-03 05:29 shovel
$ chmod go+x shovel
$ ls -l shovel     
-rw-r-x--x    1 amitg    amitg           0 2003-12-03 05:29 shovel*
$ chmod uo-rw shovel
$ ls -l shovel      
----r-x--x    1 amitg    amitg           0 2003-12-03 05:29 shovel*
$ chmod ugo+rX shovel
$ ls -l shovel       
-r-xr-xr-x    1 amitg    amitg           0 2003-12-03 05:29 shovel*
$ chmod ugo=r shovel
$ ls -ld shovel
-r--r--r--    1 amitg    amitg           0 2003-12-03 05:29 shovel
$ chmod -R o+r p
$ ls -ld p p/q
drwx---r--    3 amitg    amitg        4096 2003-12-03 05:33 p/
drwx---r--    2 amitg    amitg        4096 2003-12-03 05:33 p/q/

The u stands for user, g for group and o for other. The +, - and = specify that permissions are to be added, removed or set, respectively. The r, w and x are for read, write and execute permissions, respectively.

The other syntax takes a form similar to the umask, except that this specifies the permissions that should exist. For instance, in this example, we want shovel to be readable only by the owner and non-owning users, and writable or executable by no one.

$ chmod 404 shovel
$ ls -l shovel
-r-----r--    1 amitg    amitg           0 2003-12-03 05:29 shovel

Of course, this syntax can only express precise permissions; the symbolic syntax's + and - operators have no equivalent in this syntax.

The remaining permission bits

What about those remaining three permission bits? These are the sticky bit (t), the setuid bit (u+s) and the setgid bit (g+s). The setuid bit only has meaning for executable files. It indicates that the executable should run with the permissions of the owner of the file. If the owner is the superuser, this will result in the program having superuser access; this is used, for instance, by programs such as su and passwd, so that they can access protected files (e.g. /etc/shadow) that the ordinary user that runs the command cannot write to. Similarly, mail servers that maintain mailstores as owned by user mail will set their delivery tool to be setuid mail.

Note that if there is a security flaw in one of these setuid executables, an ordinary user need only run it and exploit the vulnerability to gain full superuser access. This would result in a local exploit. As a result, administrators always audit the setuid executables on the system, and are very conservative about what binaries have the setuid bit set. This is also why programs like the X server that need superuser privileges temporarily on startup (e.g. to take over a virtual terminal) nowadays run with the help of a wrapper that is setuid root, that does whatever setup is needed, and then drops privileges back to the level of the user that ran the program.

Analogous to the setuid bit is the setgid bit. It governs effective group ownership of executables that have it set. The scope of security issues is a bit smaller, since the root group isn't as powerful as the root user. It does, however, have an additional meaning when applied to directories under certain UNIX systems whose behavior was derived from AT&T UNIX System V. Under System V semantics, normally, a newly-created file will be owned by the primary group that its creator belongs to. However, if this bit is set on a directory, and a file or directory is created within it, the new file or directory will inherit its group ownership from the parent directory. Additionally, a new directory will also inherit the setgid permission bit.

(The group ownership inheritance behavior is the default for BSD semantics that the BSDs — FreeBSD, NetBSD, OpenBSD, BSDI, Mac OS X — follow instead. There, the setgid bit has no special significance. However, the setuid bit on a directory, while ignored under System V semantics, will cause files and directories created inside to inherit user ownership from the setuid directory under BSD semantics. Under Linux, some filesystems have a mount-time option to use BSD semantics rather than the default System V semantics.)

The sticky bit, when set on a directory, will prevent the directory from being removed by any user apart from the owner of the directory. It will also prevent users from removing or renaming files and directories owned by other users under this directory. This behavior is required for directories such as /tmp where a multitude of users may place files, so that users are not able to clobber each others' files or the directory that contains them. Modern systems ignore the sticky bit when it is set on a file, though it did have significance in older systems.)

Satisfying more complex needs with access control lists

Some more advanced filesystems like XFS, JFS, AFS and Coda have access control lists, or ACLs, and other popular filesystems (ext2, ext3, reiserfs) often have patches available to add them on. These are unlike UNIX permission bits, essentially being lists of users or groups of users along with the permissions granted to them. They're typically set with a tool called setfacl. They generally take precedence over the traditional permission bits.

ACLs are able to more completely express permissions than UNIX permission bits. For instance, consider a software project. There is one team whose job it is to architect the software system; it draws up the specification documents and organization charts. There's another team whose job it is to model the software system and to do higher-level design. Then there's a third team that runs automated regression tests. And a fourth that authors the lower-level code. And some interns that must not be able to see the overall architecture, nor the higher-level design, only the lower-level code. And marketing likes to place requirements documents for all to see.

We have identified multiple groups of users with differing levels of access at the file (or directory) level. This cannot be solved easily with UNIX permissions on a single filesystem, since we now have different groups of users requiring different permissions. Setting an ACL for each group on every directory (and files within), however, will allow for this sort of flexibility.