0x0d0a's Journal: Fixing the *IX filesystem

(reprinted from here).

I know of no distros that grant a user ownership of part of the hierarchy beneath their home directory. An example of this would make /home/ltorvalds be owned by Mr. Torvalds, but ltorvalds' $HOME be /home/ltorvalds/private.

Why is this important?

Currently, if a user wants to share files with others (or expose files to a webserver or something), it's required for them to make their home directory world-listable (and the lack of standard ACLs means that they cannot even allow "just the webserver" in, which would still be a breech of security). (They can then create ~/public_html). This is Very Bad from a security standpoint. Because *IX convention dictates that software shall store local config files under $HOME/.programname, this exposes to the entire world what programs a user runs. It also means that if the user stores any files or directories in their home directory, they are world-visible (I dunno if you like everyone with accounts on the machine being able to view your home directory, but I'm not a fan of the idea). Finally, if you're using a umask with any permission bits set for world (as is default on Red Hat and most Linux distros, presumably to facilitate sharing files that have been placed in public directories), it means that everyone can read your files. This is Very Bad. Some sysadmins work around this by scattering a user's files across the system -- creating /var/www/html/rtorvalds, say -- but then it's a pain to administer and add and remove users.

ACLs cannot fix this problem, only reduce the egregiousness of it by reducing the number of people that can be poking around in someone's private area.

A better solution (and obviously one that would cause friction for a bit) would be a reworking of the standard *IX directory layout. Here's my take on it: /home/<username> shall be chmod 751. It shall be owned by the the user and the user's private group, as shall all the directories I mention here unless otherwise noted. /home/<username>/private shall be chmod 750. $HOME shall point to this directory. /home/<username>/public shall be chmod 751. . Programs that wish to create world-readable directories owned by the user shall default to a directory created in this directory. If the user wishes to create world-readable directories, they shall be created in this directory. A good example of this is public_html. /home/<username>/dropbox shall be chmod 3777. This provides an easy mechanism to make files available to other users -- anyone can dump a file in your dropbox. Since this is sgid, not suid, it means that it will not count against uid-checking quotas, and hence cannot be used as a DoS against you.

Default umask shall be 0027, not the current (common on Linux and definitely on RH) of 0022. This makes it a harder to share files (users may hit permission problems by default when dumping things into public_html), and easier to not accidently expose masses of your own files. It's also necessary for the dropbox scheme to work without people accidently sharing masses of files that they didn't intend to.

There are a couple of disadvantages. Users have to chmod o+r files going into the /home/username/public area (at the cost of additional complexity, this can be worked around by creating an everyone group containing all users -- and naturally, having the admin tools add new users to said group -- and making the /home/username/public directory sgid and owned by that group.). There is a bit more typing (though most of what the user is working with is under ~, same as before, so it isn't a huge impact. The user gains (a) a standard way to give files away to other users, which is not currently present, (b) a standard way to make files publically available, and (c) the ability to make files publically available without revealing their private files.

Oh, yes, and (d) by changing umask to be less permissive, works around a long-standing nasty Linux security hole allowing an attacker to run amok where he shouldn't be in the filesystem. Currently, if an attacker moves into a directory when it's in a directory that he does have access to, and manages to convince a user to move that directory into an area that the attacker shouldn't have traverse access to (like that user's home directory), he is inside that area and can do what he wants until he kills the process in that directory. Since RH's umask is 0002, if an attacker can get into another user's home directory structure, he has access to read through all of their files.

Notes:

* This relies on the Red Hat style private groups scheme, where each user's primary group is a group of the same name as the user.

* I personally think that the *IX convention of dumping config data to ~/.programname should be moved to ~/.config/programname, but that's just me. It'd be faster to access a home directory, and easier to pick out data. Even if the scheme I proposed isn't adopted, this would minimize the number of things in $HOME and reduce the number of things that might inadvertently be set to be world-readable.

Agreed

[Soul-Burn666]

Even though this isn't the biggest security problem i've seen with *nix filesystems (specifically NFS), it certainly is visible.

I study at a university and every student has an account on a big mainframe for emails and such. Most people don't set their home dir permissions and a simple find or dir -s gives a nice list of open directories. Most likely people that placed a public_html in their account (as a private website) and applied wrong permissions.

Also, every time I set up a public_html for a friend,

Re:Agreed

[0x0d0a]

The problem with just tossing stuff into /tmp is that using this approach requires making the file readable by the other person.

Since ordinary *IX users cannot create groups, chgrp files to a group that they are not a member of, or chown files to a different user, unless your sysadmin has previously created a group that both the giver and the reciever are members of (and has done so for every permutation of users that might want to give/recieve files -- which is generally not even possible, since most Linu

Minor correction

[imroy]

...It also means that if the user stores any files or directories in their home directory, they are world-visible.

Um, no. You merely need execute permissions on a directory to allow another user to chdir into or through it (e.g ~user/public_html/). They would need read permissions to get a directory listing.

But you're right in that it opens the way to files and subdirectories if their permissions allow it. The attacker just needs to know the filename. And configuration "dot rc" files are easy to ge

Re:Minor correction

[0x0d0a]

Um, no. You merely need execute permissions on a directory to allow another user to chdir into or through it (e.g ~user/public_html/). They would need read permissions to get a directory listing.

You can write a short C program to try letter permutations, though, that can extract listings. Everything in my home directory would be identified by trying [-_0-9a-zA-Z.]*, and almost everything quickly by simply .?[a-z]*.

You're certainly right that it isn't as quickly exploitable as via use of read permission

overdue topic

[Eck]

* I personally think that the *IX convention of dumping config data to ~/.programname should be moved to ~/.config/programname, but that's just me. It'd be faster to access a home directory, and easier to pick out data. Even if the scheme I proposed isn't adopted, this would minimize the number of things in $HOME and reduce the number of things that might inadvertently be set to be world-readable.

This is a particularly good point. There needs to be at least a movement toward migrating all config files