Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I heard that Fedora 15 will not use suid bits. Is that true?

Is the suid bit a security design bug?

share|improve this question

1 Answer 1

up vote 9 down vote accepted

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 sudo/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 +s set.

"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.

And:

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.

And:

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.

share|improve this answer
    
+1 very nice answer –  Rory Alsop May 19 '11 at 23:00
    
The referenced page doesn't say suid isn't used any more. It says "Replace setuid apps where possible with file capabilities". So presumably suid still works at least for non-distro packages. I'd be surprised if they succeeded in converting everything. Do you know if any are left? But maybe I'm wrong: tracker bug –  nealmcb May 19 '11 at 23:10
    
@nealmcb I imagine it will both still work and still be used by third party repositories, standalone RPMs etc and you probably aren't stopped from setting the suid bits yourself. I think the aim is to encourage the main fedora repos to use this feature and package this way. Quite a lot of system services run as constrained in the targeted policy anyway (e.g. httpd_t) rather than unconfined_t anyway, so this is only a real advantage for unconfined_t domain software and people who turn off selinux. –  user2213 May 20 '11 at 8:43
    
After reading this answer and the linked resources, I'm still confused. Does Fedora 15 still use setxid bits? Does it completely remove the feature? Ship without any setxid executable but still support them? Use capabilities wherever possible but still have a few setuid programs (how do su and sudo work?)? –  Gilles May 20 '11 at 8:46
1  
@Gilles Yes, you can still use setXid bits if you want to. What they're saying is that for as many packages as possible, they won't use setuid, preferring to use capabilities. From here: forums.grsecurity.net/viewtopic.php?f=7&t=2522 it looks like there is in fact a CAP_SETUID anyway, so I expect su/sudo will use that. My rawhide is completely broken, so I can't confirm it. –  user2213 May 20 '11 at 9:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.