Use capabilities to replace SUID binairies and "shared root"

Latest response

There is a long forgotten feature in Linux (since kernel 2.2); capabilities (see man 7 capabilities).

SUID binairies are evil, because you are granting applications permissions to do anything, instead of just giving them permission for what they need to do.

The OS could allow i.e. HTTPD to only have CAP_NET_BIND_SERVICE, making it possible for HTTPD to bind to a low port, but only that.

This could seriously limit the use of a potential exploit in a web application, because an attacker gaining shell access via httpd, would only have this capability, and not be able to create users, reset passwords etc.

It should also be possible to give specific users these permissions. This way, the "root" account would no longer need to be shared, but you can give users the CAP_SYS_ADMIN capability. The best way to implement this (I think) would be a PAM "session" module. The root account can therefor be used as a "last resort", instead of just sharing, or sudo'ing. Also, logging would be user specific, and not only "root broke something".

Ofcourse, a lot of this can be implemented by using sudo, SELinux, but it would be easier if you could give users in your LDAP / NIS directory specific capabilities.

Responses

  • Not all filesystems properly support capabilities. It does not help much to implement this in a way that prevents admins from using NFS, for example.
  • In many cases, the existing capabilities are not fine-grained enough. Anything that requires CAP_SYS_ADMIN (for example) isn't really enough of a restriction over setuid root.

Good to hear.

AFAIK, any filesystem supporting xattr, should be able to support "capabilities". All filesystems offered by RHEL support xattr, so this shouldn't be a real problem.

There are ofcourse binairies which will need the full spectrum provided by CAP_SYS_ADMIN, but the point is, 95% of the SUID binairies shouldn't need this.

In addition to above

 

https://fedoraproject.org/wiki/Features/LowerProcessCapabilities

http://fedoraproject.org/wiki/Features/RemoveSETUID

 

 

I posted this over in the "Compliance with CIS or other security recommendation" thread, but I think it is appropriate here since it sounds like the parent deals with the same issue.  I had not heard of "capabilities" before and will have to learn about them.

One standard my company has to conform to is the Statement on Standards for Attestation Engagements (SSAE) No. 16 (formerly Statement on Auditing Standards [SAS] No. 70).  This standard requires us to report on the use of administrative privileges and to separate out the administrative functions.

Where this has hit us the most is in the administration of the Apache web server.  (We’ve also encountered it with JBoss and expect we’ll run up against it with other services, too.)  One basically has to be root to administer Apache after the httpd package is installed.  We need an easy way to `give` the administration of that service to another group without giving them full root access.

We opened Red Hat support case 413200, “[RFE] Apache Non-Root User Feature Request” for this.  The suggestion given by the technical support person was sub-optimal -- it was basically `as Apache admin team members are prevented from doing their jobs, create sudo privileges to fix it.`  Unfortunately, that recommendation of a very manual process was the best the support person could do for RHEL5 with the way httpd is packaged.  Maybe this can be improved in RHEL7.

Well, this isn't actually the same thing.

 

It is true, with this feature in place (including the feature to have a *user* have certain capabilities based on their login), one can administer the system (one can do the same things as root using CAP_SYS_ADMIN).

 

But, what you want (correct me if I'm wrong) is a user which is still restricted to administering the HTTPD files. You would probably have to give them -

- CAP_DAC_OVERRIDE, which enables them to write to files owned by another user

- CAP_CHOWN, which enables them to chown files owned by other users

- CAP_KILL, which will enable them to send SIGHUP or other signals to any process.

 

The problem with this; it is system-wide. A user with CAP_SETUID, could simply do:

cp /bin/bash /tmp/rootbash; chmod u+s /tmp/rootbash; /tmp/rootbash

and start a root shell (thereby having CAP_SYS_ADMIN).

 

A user with CAP_DAC_OVERRIDE could manually edit the /etc/passwd and /etc/shadow account, also wreaking havoc.

 

You will only want to give capabilities (just as sudo and SUID bits) to processes and users which you would trust with a root shell.

 

Choosing between capabilities and SUID bits, capabilities is definetly the less evil one. It is also more difficult to exploit, because it requires an extra step before actually being able to cause harm.

Bernie Hoefer, where did you post about "Compliance with CIS or other security recommendation" can you give the links site search is not returning anything useful

Hi Walid. The thread in question is here.

I found this through a Google search. I'll look into why this wasn't appearing in the Portal's internal site search.

Probably a silly question, but, what are you seeking that wouldn't be accommodated by SELinux functionality? There's likely more folks in the Linux and RedHat communities familiar with the vagaries of SEL than the Linux implementation of capabilities.

That said, the Apache.Org maintains information on leveraging the Linux implementation of POSIX capabilities with Apache (see the "NonRootPortBinding" wiki entry). For other packages, you'd want to see if the software's maintainers have made similar documentation efforts.

RedHat being mainly a distribution of specific OSS components would rely heavily on the OSS component-maintainers to appropriately enable and document their software's ability to leverage Linux/POSIX capabilities. Where RedHat is a project owner, main contributor or primary developer, it would be reasonable to expect RedHat to have unique insight into the requisite integrations. For all other OSS components, it's likely not reasonable to expect RedHat to have specific insights.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.