Use capabilities to replace SUID binairies and "shared root"
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.
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.
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.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
