I heard that Fedora 15 will not use suid bits. Is that true?
Is the suid bit a security design bug?
Correct, see this feature posted by Dan Walsh, the SELinux maintainer for Fedora/Redhat.
Summary: Fedora 15 will not ship with binaries with the setuid flag set on them, preferring instead to set the capabilities these binaries need via POSIX Filesystem Capabilities. setuid etc can still be set on binaries. Anything that absolutely must have setuid can still have it. At this time I can't confirm (my rawhide is dead) what happens with
su - it is possible for an application to use capabilities to get to root via CAP_SETUID but I don't know if they will use this technique or simply have
"suid bit = security design bug?". Well, I guess that's a matter of opinion; basically it's about giving a program that a low-privilege user uses the abilitity to run, temporarily, a privileged operation. Unfortunately, any vulnerability in that program may allow you to exploit it in order to gain higher privileges i.e. root access. Technically, it isn't a bug or a security threat; software with exploitable bugs is the issue. But writing bug free software is much more difficult than it sounds.
In terms of what posix file system capabilities are, here's a FAQ. Quoting the pertinent parts:
Then there is something quite different called "POSIX capabilities" which is what Linux uses. These capabilities are a partitioning of the all powerful root privilege into a set of distinct privileges (but look at securelevel emulation to find out that this isn't necessary the whole truth). Users familiar with VMS or "Trusted" versions of other UNIX variants will know this under the name "privileges". The name "capabilities" comes from the now defunct POSIX draft 1003.1e which used this name.
When a process tries to do a privileged operation, the operating system will check the appropriate bit in the effective set of the process (instead of checking whether the effective uid of the process is 0 as is normally done). For example, when a process tries to set the clock, the Linux kernel will check that the process has the CAP_SYS_TIME bit (which is currently bit 25) set in its effective set.
6) How can I use capabilities to make sure Mr. Evil Luser (eluser) can't exploit my "suid" programs?
This is the general outline of how this works given filesystem capability support exists. First, you have a PAM module that sets the inheritable capabilities of the login-shell of eluser. Then for all "suid" programs on the system, you decide what capabilities they need and set the allowed set of the executable to that set of capabilities. The capability rules
new permitted = forced | (allowed & inheritable)
means that you should be careful about setting forced capabilities on executables. In a few cases, this can be useful though. For example the login program needs to set the inheritable set of the new user and therefore needs an almost full permitted set. So if you want eluser to be able to run login and log in as a different user, you will have to set some forced bits on that executable.
In other words, you've got a partitioning effect for root privileges, so a setuid binary has less chance of being exploited for privilege escalation. This is good news, especially where users of Fedora turn SELinux off.
However, in a SELinux system, setuid/setguid bits are largely redundant, since selinux will apply the policy regardless of unix permissions (capabilities or otherwise). I'm going to quote a comment in the kernel source for this one:
* Since setuid only affects the current process, and since the SELinux * controls are not based on the Linux identity attributes, SELinuxdoes not * need to control this operation. However, SELinux does control the use of * the CAP_SETUID and CAP_SETGID capabilities using the capable hook.
In short, there is no need for SELinux given a properly written policy to control/restrict capability influenced behaviour, but it is used.
I'll rephrase that for clarity. In a system with a properly written SELinux policy, restricting the setting of capabilities is a non-issue since SELinux will block the activity granted by the capability if it is not also allowed in the policy. This applies to setuid/gid bits too - you might well be executing as another user, but the policy ought to stop the program doing anything outside of the defined context anyway.
An example users might be able to better appreciate/reconstruct; take a fedora box and write a basic file upload script that puts data in
/var/www/html/uploads. Taking a look at that folder you can run:
$ ls -alZ drwxrwxrwx. root root system_u:object_r:httpd_sys_content_t:s0 uploads
I'm assuming here you've run
chmod 777 on said folder. So now try your upload via Apache. You should see an AVC message; if you're running the GUI you'll find it via setroubleshoot. Basically, until you set the context of that folder to
httpd_sys_rw_content_t SELinux will deny
httpd write access, regardless of the unix permissiosn.
Want an interactive demo? Log in to this guy's machine as root.
However, there exists a concept of permissions stacking too. See this (specifically:
Add secondary calls in selinux/hooks.c to task_setioprio and task_setscheduler so that selinux and capabilities with file cap support can be stacked).
These discussed features are implemented in the above quoted source code. In other words, setting that directory to
chmod 755 yet having
httpd_sys_rw_content_t as the context will still deny write. This is because the basic unix level permissions have been denied first and so SELinux context checking is never needed.