Hello, today I want to rant about Linux permission system and how totally broken it is.
Summary of the system: In the Linux permission system each program gets one User-ID and a set of Group-IDs. Objects in the file system belong to some user, and may also be accessible to some group. Processes with the same User-ID can control each other (stop, look inside etc.). Also any process with User-ID 0 (root) can do whatever it wants to the system, including changing own User-ID/Group-IDs. Some executable files on the system may have SETUID/SETGID flag set, what means that when they're run they get an extra User-ID/Group-ID.
This is pretty much the same system Unix had 20 years ago. I think we should drop it completely and get a one that actually works.
Here's a short list of things that are wrong with the system:
- Group-IDs are per-process, not per-user. So if user fred is added to group audio, so he can play music on the computer now, the programs he is running still aren't in group audio ! So he has to log out and log in again before the change is effective. Reboot after every change ? Is it Windows 95 or what ?
- Of course the permission system isn't even supposed to run like that. The only user who can control audio should be the one that is currently logged-in to the physical console. One that is logged remotely should not have any access to the audio system. This is pretty much unimplementable with the current permission scheme.
- There are no sandboxes, in particular there are no sandboxes for normal users. So it's impossible to run untrusted programs without risk.
- There is no real nouser/nogroup. Each program in nouser/nogroup can mess with other programs in nouser/nogroup.
- There are no per-process root sandboxes either. So one cannot start a foobard server in a way that even if the server is compromised, it has access to nothing outside. If the server runs as foo User-ID it can mess with other servers with the same User-ID. Even if there's no other program with the same user-id now, it can still create a SETUID binary and control servers running with the same User-ID in the future.
- Normal users cannot install programs using standard interfaces. They should be able to install whatever they want for themselves (even if system-wide instalations still require administrator permissions).
- For single-user systems, having to remember user and administrator password is silly. Well, Ubuntu is a bit better here using sudo instead of a root account.
- Users cannot make public only one subdirectory of their home directory without granting some access to their whole directory. One might want public ~/public_html/ and private everything else. It can't be done (unless public_html is outside the normal directory hierarchy).
- There are no guest accounts, which would be created just for one session without being able to affect other guests.
8 comments:
Of course the permission system isn't even supposed to run like that. The only user who can control audio should be the one that is currently logged-in to the physical console. One that is logged remotely should not have any access to the audio system. This is pretty much unimplementable with the current permission scheme.
pam_console does exactly that. Works like charm.
Normal users cannot install programs using standard interfaces. They should be able to install whatever they want for themselves (even if system-wide instalations still require administrator permissions).
This is not a problem with the permissions system, but rather with packaging tools. It is entirely possible to install just about any program (that doesn't need to be run as root or something) just by installing it in ~/.local instead of /. AFAIK, there are some packaging tools that do such things, such as klik.
Users cannot make public only one subdirectory of their home directory without granting some access to their whole directory. One might want public ~/public_html/ and private everything else. It can't be done (unless public_html is outside the normal directory hierarchy).
It's enough to have only o+x on ~, and then o+rx on public_html. o+x does not really grant any access.
So it sucks for single-user desktop, it sucks for multi-user desktop, it sucks for public access terminals, and it sucks for the server. Why are we still keeping it ?
Perhaps because it doesn't suck nearly as much to change it? Keep in mind that there ARE other permissions models available, with grsec, selinux and ACLs. Some distributions even use them by default (PLD, I think). Still, it's cumbersome and most people are used to standard unix stuff. Worse is better, I guess.
pam_console does exactly that. Works like charm.
How does pam_console deal with the following "exploit":
$ cp /bin/bash xploit
$ chmod 0750 xploit
$ chgrp audio xploit
$ chmod g+s xploit
$ ls -l xploit
-rwxr-s--- 1 taw audio 664084 2006-07-03 15:24 xploit
This is not a problem with the permissions system, but rather with packaging tools.
You are correct from implementation point of view that I'm blaming the wrong thing, However from user perspective "having to enter root password to install programs" is just a permissions issue. In any case this is another thing that sucks about Linux.
It's enough to have only o+x on ~, and then o+rx on public_html. o+x does not really grant any access.
Well, o+x grants some access, like I know you have /home/divide/furryporn/ in your home directory now and I wouldn't if you had o-x ;-p
However the problem is somewhere else.
The user would have to set umask to 0077 (so that other files in their home directory wouldn't be accidentally made readable), and then explicitly mark all files in public_html uog+r so they're readable to everyone.
This sucks as we simply want to have all files in public_html readable, and all files in home directory not accessible in any way. So the only reasonably convenient setup is to have public_html in something like /home/public_html/user_name (and I don't know any distros that are setup like that).
Perhaps because it doesn't suck nearly as much to change it? Keep in mind that there ARE other permissions models available, with grsec, selinux and ACLs. Some distributions even use them by default (PLD, I think). Still, it's cumbersome and most people are used to standard unix stuff. Worse is better, I guess.
Yeah, there are a few projects, but I'm not they seem to be only into making servers more secure, not into making the whole system more usable from user/admin perspective. And can you even make public public_html within completely private homedir in any of them ?
How does pam_console deal with the following "exploit":
$ cp /bin/bash xploit
$ chmod 0750 xploit
$ chgrp audio xploit
$ chmod g+s xploit
$ ls -l xploit
-rwxr-s--- 1 taw audio 664084 2006-07-03 15:24 xploit
Have you even tried that? Running that `exploit' won't get you into audio group if you are not their member or root. If you are, well, it just changes GID of the process from whatever is your default group (users, root, etc.) to audio.
Besides, pam_console does a different thing: it does
# chown logged_user /dev/audio/*
# chmod 600 /dev/audio/*
so any group magic won't do you shit.
Well, o+x grants some access, like I know you have /home/divide/furryporn/ in your home directory now and I wouldn't if you had o-x ;-p
No, you don't. You need +r to list directory contents. With only +x you can only cd into it.
However the problem is somewhere else.
The user would have to set umask to 0077 (so that other files in their home directory wouldn't be accidentally made readable), and then explicitly mark all files in public_html uog+r so they're readable to everyone.
That's true. However AFAIK ACLs solve that issue by having objects inherit perms from parents.
Yeah, there are a few projects, but I'm not they seem to be only into making servers more secure, not into making the whole system more usable from user/admin perspective. And can you even make public public_html within completely private homedir in any of them ?
See above about ACLs. You still need to have o+x perms on the homedir, though. Not that it matters, as, as I stated above, it doesn't allow people listing contents.
Darn, my cool setgid exploit doesn't work ;-)
Anyway, you cannot list content directly, but you can check whether content is present:
$ ls -ld /home/divide/
drwx--x--x 3 divide divide 80 Jul 3 18:35 /home/divide/
$ ls -l /home/divide/
ls: /home/divide/: Permission denied
$ ls -ld /home/divide/furryporn/
drwx------ 2 divide divide 48 Jul 3 18:35 /home/divide/furryporn/
$ ls -ld /home/divide/warez/
ls: /home/divide/warez/: No such file or directory
It's not that hard to try all possible suspicious file names with a script then :-p. It's not much access, but it's somewhat annoying nonetheless.
No, you don't. You need +r to list directory contents. With only +x you can only cd into it.
BTW. This is also not true as it all depends on Apache in the end ;P.
This is not a problem with the permissions system, but rather with packaging tools.
You are correct from implementation point of view that I'm blaming the wrong thing, However from user perspective "having to enter root password to install programs" is just a permissions issue. In any case this is another thing that sucks about Linux.
No, this is a wonderful feature, because having system programs and libraries inaccessible by ordinary users prevents most of the malware that afflicts Windows users. Windows Vista is pushing Windows in this direction for this very reason.
As for classic UNIX permissions, yes, they're inadequate, but there are solutions. I've usually worked in an AFS environment, which fixes many of the problems you cite and all of the ones that bother me, but it seems that POSIX ACLs are the most widely installed system. Try "man setfacl" for details.
No, this is a wonderful feature, because having system programs and libraries inaccessible by ordinary users prevents most of the malware that afflicts Windows users. Windows Vista is pushing Windows in this direction for this very reason.
They tried, and users always pushed back successfully. Because installing software is a basic activity - I'm doing it almost every day, without thinking, and so do most other people. For big things, it's not that common, but imagine having to ask an admin to install or update a Firefox plugin. That's just sick.
As for classic UNIX permissions, yes, they're inadequate, but there are solutions. I've usually worked in an AFS environment, which fixes many of the problems you cite and all of the ones that bother me, but it seems that POSIX ACLs are the most widely installed system. Try "man setfacl" for details.
Filesystem is only part of the issue. You also need to manage things like IPC rights (what process can signal/ptrace what other process), device access etc.
But at least for the filesystem issues, how does AFS or POSIX ACL solve the problem ? I always had an impression that they still operate within the rwx system, and just allow you to specify with better granularity who gets rwx rights.
If I understand it right, this is completely insufficient even for something as simple as this - I want /home/taw/ to be totally off-limits to everyone, and /home/taw/public_html/ universally viewable. Can AFS/POSIX ACL handle that ?
I investigated the issue and it seems that POSIX ACLs suck as much as Unix system, but shockingly Windows ACLs do the Right Thing.
In particular:
Since Windows 2000, Microsoft uses a dynamic inheritance model that allows permissions to propagate down the directory hierarchy when permissions of parent directories are modified. POSIX ACLs are inherited at file create time only.
This is awesome. It means private /home/taw/ and public /home/taw/public_html/. Also:
Windows ACLs support over ten different permissions for each entry in an ACL, including things such as append and delete, change permissions, take ownership, and change ownership. Current implementations of POSIX.1 ACLs only support read, write, and execute permissions.
and so on.
I know Microsoft is evil, engages in various illegal and unethical activities, most of their software produces large amounts of vacuum, MSIE and Outlook were crimes against humanity that should get a few people life sentences in the International Criminal Court, and the only Microsoft product I enjoy using is Microsoft Natural Ergonomic Keyboard 4000.
But in this one case - Windows is so much better than all Unices, it's like Firefox 2 vs. MSIE 4 in reverse.
Post a Comment