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
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
new permitted = forced | (allowed &
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.