LWN.net Logo

Inside SELinux on Fedora Core 3

October 6, 2004

This article was contributed by Jake Edge.

Following up on a previous overview of Security Enhanced Linux (SELinux), this article looks more closely at the implementation of Security Enhanced Linux (SELinux) in Fedora Core 3 test2 (FC3).

FC3 provides two separate SELinux policies, a default "targeted" policy and the more restrictive "strict" policy. The targeted policy focuses on a handful of specific system daemons and locks down their access while allowing the rest of the system to run using the standard Linux security mechanisms. The FC3 SELinux FAQ describes the reasoning behind the targeted policy:

Initially, when SELinux was included in Fedora Core, the NSA strict policy was enforced. For testing purposes, this helped to find hundreds of problems in the strict policy. In addition, it became obvious that applying a single strict policy to the many environments of Fedora users was not feasible. Managing a single strict policy for anything other than default installation was going to require local expertise.

There are 9 daemons currently handled by the targeted policy, all network services of various sorts (httpd, named, snmpd, etc.) and more daemons will be added to the policy in the future.

The top-level configuration file (/etc/selinux/config) for SELinux on FC3 allows one to choose which of the policies to use and also what enforcement level to use. In particular, the "permissive" level is useful for finding problems in the policy for a specific installation as it just warns when the policy has been violated. Once the policy has been adjusted, the level can be set to "enforcing," which will cause SELinux to enforce the policies. In addition, the enforcement level can be set to "disabled" which effectively turns off SELinux. Any changes made to the configuration file require a reboot to take effect, but the enforcement level can be changed in a running system using the setenforce command.

While changing the enforcement level is painless, the same is not true for changing policies. SELinux uses the extended attributes in Linux filesystems to permanently associate a security context with each file and when changing policies, the attributes of many files in the filesystem must also be changed. The fixfiles command is available to traverse the filesystem and make the required changes based on the information provided in the file_contexts file associated with the policy. file_contexts maps a regular expression describing some subtree of the filesystem (possibly down to an individual file) to a security context and fixfiles (and the related setfiles command) parse this file and set the attributes appropriately. FC3 puts the SELinux configuration in the /etc/selinux directory and the specifics for each policy in /etc/selinux/<policyname>. For example: /etc/selinux/targeted/contexts/file_contexts provides the security context configuration for files in the targeted policy.

To support examining the security context of various entities in the SELinux system, the -Z command line parameter has been added to several standard utilities. The ls, ps, and id commands have been modified to display the security context of files, processes and users respectively and are very useful when diagnosing policy issues.

To get a sense of what goes into the policy configuration and how complex it is, we examined the targeted policy configuration for the ntpd program. Once the selinux-policy-targeted-sources package is installed, the configuration file for ntpd can be found in /etc/selinux/targeted/src/policy/domains/program/ntpd.te. This file specifies the access that the daemon will be allowed to have and should specify all of the system entities (files, sockets, etc.) that the program needs to access for correct operation. The level of detail required in this file is rather eye opening:

  • Types are defined for the drift file and for the network port used by ntpd
  • All of the file and directory types that are used by the daemon are also specified with what access is granted for each
  • Read access is granted for the urandom device
  • Network access is granted
  • Access to bind to the udp port that it uses and socket creation access for datagram and stream sockets is granted
  • Capabilities allowing it to use the nice() system call are granted
  • etc.
It would appear that a fair amount of work went into figuring out all of the various pieces that go into this configuration for what, at first blush, would seem a fairly simple system daemon. Multiply this level of complexity by the number of daemons in a typical system and one can see why some critics of SELinux call it too complicated to be useful. On the other hand, SELinux does provide very fine grained control over access to system resources and in certain applications, that control is very desirable.


(Log in to post comments)

Inside SELinux on Fedora Core 3

Posted Oct 7, 2004 21:25 UTC (Thu) by iabervon (subscriber, #722) [Link]

On the other hand, if it is this modular, projects could just include the file (or generate it at build time, to account to configuration dependance). It sounds like a nice description of what the program affects, and if it is enforced by developers' systems, it will probably stay up-to-date. It would be much easier to keep track of where apache's config files are in the local installation if the OS was specifically granting Apache permission to read them.

Inside SELinux on Fedora Core 3

Posted Oct 8, 2004 14:02 UTC (Fri) by erich (subscriber, #7127) [Link]

But it is an issue of trust. If the policy file is included in a normal package, upgrading this package could in fact disable or break your whole selinux policy. You don't really want that.
Currently, Policy changes are made using at least four eyes. (i.e. the redhad guys send them to the mailing list, and a NSA guy reviews them, comments on them, tests them and then commits them to CVS on sourceforge)
I think this makes a very good policy, and avoids ugly workarounds etc.
I bet many application writers will be so proud of their software to give it a lot more rights than needed. Also while debugging you will want to have additional rights that do not need to be included in the normal policy.

Many policy files already contain debian package information.
I.e. it is possible to write a helper program which will install just the policy files for the installed debian packages. Right now this is not included in the selinux-default-policy package (which is a strict policy, btw), instead you will be asked for each file if you want to install it.

Inside SELinux on Fedora Core 3

Posted Oct 8, 2004 15:21 UTC (Fri) by iabervon (subscriber, #722) [Link]

I wasn't thinking that the project's suggestion should be installed automatically. But the project is essentially authoritative as to what the program is going to try to do when functioning as intended, so it would be helpful to look at when deciding what to set as the policy.

Inside SELinux on Fedora Core 3

Posted Oct 10, 2004 13:44 UTC (Sun) by erich (subscriber, #7127) [Link]

Granted. Once SELinux is widely enough adopted this might become an option.
Still its also about looking applications over the shoulder and limiting them to what they should do, not what they want to do.

Inside SELinux on Fedora Core 3

Posted Oct 8, 2004 1:08 UTC (Fri) by mongre26 (guest, #4224) [Link]

Multiplication of the complexity is only applicable if you assume a worst case scenario.

While it may be complex to implement SELinux to apply to every single daemon on a multi-user system with dozens of daemons that interact with users, the issue is a lot simpler on say a web server.

A web server may run 3 or 4 main daemons with external access.

sshd for management
httpd for web server
tomcat for java applications
mysql for a database

Other than that daemons either do not need to be run at all (xinetd), are local only (crond), or are part of the kernel daemons (kswapd).

For a system like this, which you want to be secure as possible from external threats, you have something like SELinux prevent externally listening daemons from being used to gain unauthorized access.

The approach of profiling only a few daemons is more valuable that it might first appear. That some people might argue against SELinux because of complexity it seems they may be setting SELinux up by selecting the worse case scenario. A scenario that is unlikely in a lot of application spaces.

The selected list of daemons is a good one, and reflects a good start.

Also once a profile is done, a lot of the hard work is complete. Then you can distribute the profile widely. The model scales well, it is just it needed a bit of a kick to get going. This is definitely a good start.

Not that management tools do not need improvement. Once you do get a lot of profiles you really need a system to effectively manage and modify them.

Inside SELinux on Fedora Core 3

Posted Oct 8, 2004 14:12 UTC (Fri) by erich (subscriber, #7127) [Link]

One of the big problems of SELinux (and any other process-based access control system, including unix access rights) and Java (and any other VM system, designed to run applications inside a big process, including libapache-mod-perl and PHP) is that it cannot tell the difference between the different users owning the applications or the applications themselves.
For SELinux (or Unix...) the applications at still the calling apache (or tomcat, whatever), running in the apache domain, using the apache userid (www-data etc. usually)
This is a big problem with Java, PHP & Co. If you want to build a secure system you'll want to run every application in a separate domain. Big VMs make this way to slow.
Unless someone comes up with a way of having Java or PHP being a service and cheap (= little memory, little startup) slave daemons that run in separate security contexts, i will avoid using these.
In fact, shared libraries solve this mostly for C applications.
Of course for important apps you can run an own java VM or PHP daemon using FastCGI to get the security back.
Or you can try to compile java apps using gcj.

Inside SELinux on Fedora Core 3

Posted Oct 10, 2004 12:10 UTC (Sun) by steffen (subscriber, #23586) [Link]

Would not Apache + PHP using FastCGI the solution to the problem you mention?

Inside SELinux on Fedora Core 3

Posted Oct 10, 2004 13:42 UTC (Sun) by erich (subscriber, #7127) [Link]

Yes, but you would need to run a separate PHP interpreter for *each* independent service with different access rights.
I.e. for each user using php.
Same for Java. And each needs its own not-too-tiny share of memory, etc.

Also the fastcgi apache modules are not considered DFSG-free.

I already mentioned FastCGI in my posting, btw.

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds