Security

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:

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:

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:

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:

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:

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.

Comments (26 posted)

PHP 5.2.7 withdrawn

Update: PHP 5.2.8 is now available.

Comments (18 posted)

Archive::Tar: directory traversal

Comments (none posted)

awstats: fix incomplete fix for CVE-2008-3714

Comments (none posted)

clamav: denial of service

Comments (none posted)

compiz-plugins: illegal access to desktop

Comments (none posted)

dbus: security bypass

Comments (none posted)

java: arbitrary code execution

Comments (none posted)

java-1.6.0-openjdk: multiple vulnerabilities

Comments (none posted)

kernel: buffer overflow

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: privilege escalation

Comments (none posted)

kernel: denial of service

Comments (none posted)

lcms: buffer overflows

Comments (none posted)

mgetty: insecure use of tmp file

Comments (none posted)

apache: multiple vulnerabilities

Comments (none posted)

ruby: denial of service

Comments (none posted)

squirrelmail: cross-site scripting

Comments (none posted)

syslog-ng: chroot jail escape

Comments (none posted)

vim: information exposure

Comments (none posted)

vinagre: format string flaw

Comments (none posted)