http://lwn.net/Articles/309665/Security[LWN subscriber-only content]Fedora and CAPP Removing the ability for regular users to execute "system" programs has a certain appeal, but does it really provide any extra security? A thread on the fedora-devel mailing list explores that question in the context of usermod (and other, similar tools), which had their permissions changed more than two years ago in an effort to meet security certification requirements. Whether these changes, and at some level the certifications themselves, actually increase the security of the system is the open question. Callum Lerwick noticed that running usermod no longer worked as a regular user. He has a habit of doing that to get a quick overview of the command syntax and options from the help page, but unless he uses sudo, that doesn't work. That was done on purpose as Steve Grubb describes: These should have been gone for quite a
while...and on purpose. You cannot do anything with them unless you are
root. Allowing anyone even to execute them would require lots of bad
things for our LSPP/CAPP evaluations.
LSPP and CAPP are two protection profiles that are used for Common Criteria security certifications (such as EAL3) that Red Hat Enterprise Linux (RHEL) has earned. Because these tools can modify trusted databases (e.g. /etc/shadow), attempts to run them by untrusted users must be added to the audit log in order to comply with the certifications. But adding audit events requires the CAP_AUDIT_WRITE capability bit; in today's systems that effectively means setuid(0). As Grubb puts it: "IOW, if we open the permissions, we need to make these become setuid root so that we send audit events saying they failed." Leaving aside the idea that only processes with root permissions are allowed to generate auditable events―which seems a bit bizarre―there is still the question of how much protection is provided by changing the file permissions. Seth Vidal asks: And do we seriously think we can keep the code
away from a non-root user by chmodd'ing the binaries? A user can get a
binary for anything fedora can install in about 30s w/firefox.
Allowing users to download binaries "takes the system out of the certified configuration", according to Grubb, "So, if you need to be in the CAPP certified configuration, don't let users do this." This fairly clearly demonstrates the dubious nature of the security afforded by the current certifications. For the most part, the protection profiles define away nearly all of the interesting threats that most systems face today. To a large extent, CAPP/LSPP certifications are the kinds of things listed in marketing materials for "enterprise" operating systems rather than serious attempts to address the real security needs of the vast majority of network connected systems. Grubb provides an excellent overview of some of the requirements of CAPP, along with how they are implemented in Fedora as part of the discussion. The CAPP information page gives the full story, however: The CAPP provides for a level of protection,
which is appropriate for an
assumed non-hostile and well-managed user community requiring
protection
against threats of inadvertent or casual attempts to breach the system
security. The profile is not intended to be applicable to circumstances
in
which protection is required against determined attempts by hostile and
well-funded attackers to breach system security.
But CAPP does require that all attempts to modify trusted databases like the shadow password file generate an audit trail, so there is a lower-level audit rule set up for that file. Any access to /etc/shadow, for example, is logged as Grubb describes in his overview. That, though, begs other questions as Lerwick points out: So we *are* auditing low level filesystem calls?
So then what, other
than security theater, does auditing execution of usermod gain us?
The answer is that auditing execution of usermod by non-root users gains exactly one thing: CAPP compliance. It requires that binaries which modify trusted databases leave an audit trail. Even though any actual attempt to access the underlying file will be logged, just accessing the binary that could modify the file is also something that must be logged. Part of the dismay displayed in the thread comes from the fact that Fedora will probably never be certified with CAPP for any number of reasons. So taking away longstanding user abilities, though there are reasonable alternatives like man usermod, for a certification that won't be done, doesn't sit well with some in the Fedora community. Though, as Jef Spaleta notes, there might be a use for the certification in a Fedora spin: Is there need for certified
'appliance' situations that a new 3rd party could leverage Fedora to
create? I can imagine all sorts of no network software appliance
situations where the CAPP certification applies and a Fedora derived
image would be a good development target.
There is always going to be tension between the security needs of an "enterprise" distribution like RHEL and a more user/desktop-oriented distribution like Fedora. While the specific reduced functionality in this case is fairly minimal, the discussion increased the visibility of the auditing required for certification as well as what that means for both distributions. The original decision was made back in the Fedora Core days when there was much less visibility and community input into the process. Discussions like this will only help continue the process of opening up Fedora while also exposing some of the inadequacies of security certifications. |
- [linuxkernelnewbies] Security [LWN.net] Peter Teoh
- [linuxkernelnewbies] Security [LWN.net] Peter Teoh
