Journal 0x0d0a's Journal: Fixing the *IX filesystem 6
(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
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
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:
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
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 (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:2)
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
You're certainly right that it isn't as quickly exploitable as via use of read permission
overdue topic (Score:1)
This is a particularly good point. There needs to be at least a movement toward migrating all config files