During my tenure at Gentoo, running the Hardened Gentoo project, the most common question by far was “How do I secure my system?” Warning, this article may contain some flamebait, avoid it if you can’t resist flaming back ;).

Eventually we gave up and just pointed people to websites, perhaps this post can serve as that page. The answer was “What do you mean ’secure’ your system?” Security isn’t, and can’t be, a goal by itself. You need to know what exactly you are trying to protect yourself against, your threat model, as it were.

SELinux has the ability to protect against many different threat models. In Hardened Gentoo we also had some complimentary projects that protected against things that SELinux couldn’t, such as PaX (kernel level memory execution protection and memory layout randomization) and SSP (userspace level stack smashing protection). Fedora also has comparable technologies such as Exec Shield baked in by default.

So I saw a thread recently that said something to the concern of “Why use SELinux, which is security bolted onto Linux when you can use OpenBSD which has security as part of the development process?” It’s an interesting question I suppose, if you can decode it. The OpenBSD mantra seems to be develop software correctly in the first place and you don’t need additional layers of security. The baffling part is that you’ll rarely find an OpenBSD user that actually knows what security OpenBSD actually, tangibly provides.

All that said, there are different kinds of security that you might want to implement, and lots of different solutions to attain them.

System Integrity

System integrity is what most people mean when they say “secure my system”. Do you want system integrity? The answer is almost always yes. Some people want very good system integrity and end up using a read only medium, like a livecd or dvd, to run their systems. This, of course, only works if you aren’t storing important data on those systems, for things like web front ends to applications servers it might work fine.

System integrity is what OpenBSD users mean when they say they have a secure system. They integrate quality control into their development process to ensure that as few bugs as possible get into their code and the result is suppose to be high system integrity.

Quality control alone doesn’t give you complete system integrity, however. Your kernel can be well coded but that doesn’t mean much if other processes running as root are vulnerable. Just take a look at ps and see how many applications are running as root. If any of those services are vulnerable your system may have less integrity than previously thought. The fact is everyone runs third party apps on their UNIX/Linux systems. Most users run Apache, samba, syslog, etc and all have components running as root. Even OpenBSD isn’t without vulnerabilities, quality control only goes so far, after that more is necessary.

Memory protection techniques can help protect against some of these vulnerabilities. NX support on modern processors prevent some exploits that use bugs to add shellcode to running applications but that won’t prevent someone from using code already present in the address space, such as system(). Memory layout randomization only provides stop gap protection since the layout can eventually be brute forced, if the administrator isn’t watching very closely.

Mandatory access control is a way of addressing the gaps between a well coded kernel and vulnerable third party applications. If Apache shouldn’t be able to write to anything in /usr then MAC can prevent that. This, by itself, is a huge win for system integrity since it is generally thought that /usr is the highest integrity part of the system.

Now for some explanation. On most systems you can think of integrity as either low or high. High integrity files are files that are system objects. Things in /usr are pretty much all system objects. If a system object gets changed the behavior of the system is changed. A rootkit is going to target these high integrity files, for example. Other examples of high integrity objects are, ofcourse, anything in /boot, /lib, /sbin, /bin, most files in /etc, and so on. User files, on the other hand, are generally low integrity files. Anything in /home is untrusted. User data should never be able to affect the integrity of the system.

The integrity of a process is determined simply by where it gets its input. If a process reads user data, or data off of an untrusted network it is considered low integrity. Apache, which reads /home/*/public_html and receives queries from the internet, is low integrity. RPM, which is run by the administrator, reads rpm’s downloaded from your vendor (hopefully) and installs files all over the system, is high integrity (this is an assessment of how it operates, not whether it is free of vulnerabilities).

Now that you know how to determine the integrity level of objects and processes lets talk about the security policy to maintain system integrity. Biba is a hierarchical integrity policy, similar to Bell LaPadula but, interestingly, the exact opposite. It allows processes to both read and write to objects of the same integrity, no surprises there. Next it allows high integrity processes to write to low integrity objects, but not read them and last it allows low integrity processes to read high integrity objects but not write them.

Though the use of Biba is very limited and has never hit a mainstream operating system it is a very good practice, if implemented in a usable way. The standard SELinux policies implement something between Biba and ‘least privilege’, with a nice balance to ensure system integrity without making the system completely unusable. Biba, for example, isn’t very flexible. Since processes and objects are simply labeled with their integrity there is no way to make practical changes to the policy. You either fall within the constraints of Biba or you are entirely MAC exempt.

The SELinux Apache policy doesn’t allow Apache to write to the high integrity files we talked about above (/usr, /lib, /bin, etc) while allowing it to write to its logs, its cache, etc. Since objects in SELinux have fine grained labeling we can restrict access to apache high integrity objects, such as apache modules, the apache configuration and so on. In many ways SELinux lets us constrain applications more than Biba while at the same time making practical exceptions when necessary. This brings me to my next kind of security.

Application and Data Integrity

While system integrity is generally of the utmost importance, since it is the basis on which you can build other security goals, in some cases it is not enough. Sometimes the most important part of a system is the applications it is running, or the data those applications manage.

For example, if you are running a database server the most important part of the system quite possibly could be the data in that database. How do you protect that data?

We can go back to the mantra of well coded systems with quality control but that, once again, fails when you consider other applications running on the system. Granted you’ll need to trust the database server itself with the data, there is no way around that but the other applications that can access the data can be problematic. Generally database files would be owned by a non-root user with the correct permissions set to prevent other applications from accessing them without going through the database server. Of course root applications can bypass all those restrictions.

There are multiple ways to protect the data. One way is run only the database server on the system and nothing else. That way there is nothing else to protect the data from. This can work in well controlled environments but there are always going to be apps running, like the system logger and sometimes, particularly on UNIX like systems, there is a tendency to put multiple applications on a single system. There will always be the need for backup apps, log monitors, log rotators, etc. This may be a risk you are willing to take, and that is what threat modeling is all about. If you can accept the risk then your security may already meet your needs.

Another way people have tried recently is with hypervisors. Unfortunately the current generation of hypervisors always require a domain 0 or host OS that essentially has full access to the disk, the network interfaces, sometimes the memory, etc. Protecting the integrity of applications within a VM is impossible without first doing so on the host OS, as I pointed out in my Blu-ray post.

MAC systems are IMHO a superior way to handle application and data integrity. SELinux policies can prevent anyone from accessing the database files aside from the database server itself. You may need the backup service to read the database files directly (unless it is configured to get backups directly from the database server itself) but you can easily make the backup server only able to read files without being able to write them, which is not something you can easily do without MAC.

Pipelines

Another security goal which is often overlooked outside of a small niche of guard architects are pipelines. Guards are systems with specific purposes to transfer data from one side to another, while going through a specific set of applications. In the real world one can envision a proxy server or a virus scanning email server as a guard. The idea is that data coming into a system must go through some number of applications before it is allowed to proceed.

In this security goal it is desired that any incoming email goes through a virus and spam filter before going on to the user mail directory and ultimately onto the end users system. This may be more of a functional goal than a security goal to some. As a former administrator I understand the security ramifications of unfiltered email getting through to the network. This kind of goal is generally enforced with configuration of the mail system but for some people that is not enough.

Pipelines obviously rely on system integrity to protect the layer below the pipeline itself, so those security goals are composed onto one another. An opensource project that my company developed called CDS Framework implements this sort of security goal.

Conclusion

There are other security goals one can implement, these are only examples. The first two are probably the most important for most users. The main thing I want people who read this to take away is that there is no such thing as a ’secure system’ or ‘added on security’ or ‘baked in security’. Security by itself doesn’t mean anything. Users need to determine their threat model and security goals in order to determine what measures need to be taken in order to protect what they want protected.

Disclaimer: I am an HDDVD owner but this post is not a result of bitterness about my chosen format losing. The reason I’m posting here about (among others) is the actual reason I chose HDDVD. I also don’t want to talk about the pro’s and con’s of DRM or whether the DRM has been cracked and is accessible via other means. I am going to talk about the intentions of the format producers and what it means to consumers.

So, basically the big security problem I have with Blu-Ray is that BD+ (a BluRay specific DRM mechanism) has some scary provisions to make movie producers happy. Basically the idea behind BD+ is that the movie, decoding, etc is done from within a virtual machine.

So the problem with using a virtual machine to protect the data from the person who owns the device is that the host inherently can access and manipulate the virtual machine itself, including the data. This presents a fundamental problem with the idea of protecting the content. So in order to address this the movie producer must be satisfied that the host machine is in a state where the virtual machine is considered safe.

This is where BD+ gets scary. It allows movie producers to package arbitrary host executables with the BD+ virtual machine that is run on the player before the virtual machine unencrypts any content. The idea, of course, is that a vulnerable host (that is, a host that allows unauthorized access to the unencrypted content) can be patched in order to close the vulnerability. This has some serious ramifications including, but not limited to, producers being able to rootkit machines (see sony’s recent rootkit fiascos), spyware, broken patches that make systems more vulnerable, broken patches that break machines, patches that affect different OS releases differently, etc.

I almost wish a producer would create a PS3 patch that bricks a bunch of PS3’s just to show how very very dangerous “features” like this are.

So that is one of the features that scared me the most. There are other problems I had that caused me to choose HDDVD such as incomplete specifications for BluRay, fewer features in the original specifications, limits on the layering of the disks and so on. I now have a dilemma about whether to get a BluRay player knowing that, as a consumer, the choices I make validate the behavior of the producers. The most disturbing fact is that the consumers who don’t know about these issues have implicitly allowed the format producers and movie producers to build this incredibly anti-consumer system. C’est la vie I suppose.

inode-based security has analogous problems to path-based security. Software opens paths, not inodes, so it very much matters what the permissions are for the file at /etc/shadow or /var/data/mydb, regardless of what the inode happens to be. With an inode-based system, security may go out the window when programs replace or manipulate inodes, as many of them do.

Software opens paths because paths are the exposed abstraction for userspace applications. Sure it matters what permissions are on /etc/shadow, but those permissions and the access control alike is always done at the inode level, as I will demonstrate below. Applications that manipulate inodes have always needed to set security attributes on those inodes, look at passwd source code and you will see that it creates the inode with mode 400 (r——–).

So, neither AppArmor nor SELinux provide bullet proof security or data integrity, although both may be useful in protecting against some problems.

This is blatantly wrong, SELinux provides controls to specify precisely how things can be labeled. If my policy does not allow an application that handles confidential information to relabel or create a file with a label that is accessible by other applications there are no circumstances where that application will be able to leak the data. Similarly if an application can’t read low-integrity data and write to high-integrity files there are no circumstances where the application can harm the data integrity. I suggest you read some of the papers about SELinux policy analysis and information flow to understand the issues and how SELinux can address them. Many are available at the SELinux symposium website.

But arguments like the ones in this blog really make me doubt whether the SELinux people even understand the issues or have much of a notion of how files and security work on real-world UNIX systems.

As much as I’d like to ignore people using ad hominum attacks there may be others under this impression. Note the following demonstration as a counter example:

# ls -al /etc/shadow
-r-------- 1 root root 947 2007-06-06 03:40 /etc/shadow

# ln /etc/shadow /tmp/shadow
# ls -al /tmp/shadow
-r-------- 2 root root 947 2007-06-06 03:40 /tmp/shadow

# chmod 777 /tmp/shadow
# ls -al /etc/shadow
-rwxrwxrwx 2 root root 947 2007-06-06 03:40 /etc/shadow

It should be clear at this point that the UNIX permissions absolutely do not have anything to do with paths, only with inodes. This is how real-world UNIX systems have always worked, path based mechanisms break that convention and are subject to the issues I’ve noted in the path based article. The simple fact is that UNIX systems never ever use paths to determine access to anything, access control has always been centered around inodes and permissions set on inodes. Do not think that the existance of paths changes that, these are merely an abstraction to make userspace more useful.

The arguments against SELinux by the AppArmor people, and others, are purely functionality based arguments. They want to use paths because paths are easy to understand and paths have conventions that can be reflected in their policy (eg., that passwords are always stored in /etc/shadow and therefore that file should be protected). SELinux provides mechanisms to enforce many different security policies including protecting /etc/shadow and /var/data/mydb.

Network support in SELinux means many things. In the old days (“old days” is very relative since it was only a few kernel releases back at this point) SELinux had fine grained network access control by way of many object classes. These object classes were netif (network interfaces), node (network addresses) and a handful of socket object classes (such as tcp_socket, udp_socket, rawip_socket and so on).

The SELinux policy directly labeled several kinds of network objects including interfaces (using netifcon), internet nodes (using nodecon) and ports (using portcon). The policy statements looked something like these:

netifcon eth0 system_u:object_r:external_netif_t system_u:object_r:external_packet_t

nodecon 192.168.1.1 255.255.255.255 system_u:object_r:external_node_t; portcon tcp 21 system_u:object_r:ftp_port_t ;

These labeled objects could then be given access to with normal SELinux rules:

allow ftpd_t external_netif_t : netif {tcp_send tcp_recv };

allow ftpd_t external_node_t : node { tcp_send tcp_recv };

allow ftpd_t ftp_port_t : tcp_socket { send_msg recv_msg name_bind };

These basically gave ftpd_t the ability to bind to port 21, send and receive tcp messages on port 21 and send and receive tcp messages on eth0 (whose ip was 192.168.1.1). These worked fine, the only problem is that they weren’t specified in a single rule so they weren’t coupled. This means if there was another set of rules that let ftpd_t send and receive dns packets (for name resolution) only on the internal interface they could also send and receive dns packets on the external interface by virtue of the rules above. Note that these access controls can still be used en lieu of the ones I’m going to talk about next by setting the compat_net option in SELinux with echo 1 > /selinux/compat_net.

The labeling of these objects was eventually added to libsemanage and could be changed on end systems using the semanage command without modifying policies.

During the 2006 SELinux Symposium Developer Summit we discussed ideas on making the network labeling easier to use, more able to support typical network restrictions and most importantly to closely bind the interface, address and port. Fortunately for us netfilter in Linux already supports all these things as well as some additional benefits like connection tracking that can be used to more precisely restrict things that use dynamic ports such as ftp.

One may be thinking that the easiest way to handle this is to add a domain specifier to iptables so that one could write a rule that matched the SELinux domain as well as the ports, network interface and addresses to allow only ftp packets to reach ftpd_t. This would have decentralized the SELinux policy, however, by moving part of the decision making out of the SELinux security server and into the iptables policy and subsystem. This is generally undesirable as we’d like to keep a single, centralized, analyzable SELinux policy. That essentially left us with using netfilter and iptables to label packets, which would have SELinux allows rules written to allow or deny access. Lets look at how this might be used:

iptables -A INPUT -t mangle -p tcp --dport 21 -j SECMARK --selctx system_u:object_r:ftp_packet_t

This labels packets destined for port 21 as ftp_ packet_t. The SELinux rule that allows ftpd_t send and receive packets of this type is simply:

allow ftpd_t ftp_packet_t : packet { send recv };

But this doesn’t do anything more than the old network controls did, lets look at something more interesting:

iptables -A INPUT -t mangle -p tcp --dport 21 -i eth0 -s 192.168.0.1/24 -j SECMARK –-selctx system_u:object_r:ftp_packet_t

This labels only packets on eth0, coming from 192.168.0.1/24 and on tcp port 21 as ftp_packet_t. So this has the advantage of being able to couple anything that netfilter supports together. Another iptables rule such as:

iptables -A INPUT -t mangle -m state --state RELATED,ESTABLISHED -j CONNSECMARK –restore

will copy the label for related packets so when an ftp client attempts a file transfer the related port (which is dynamically assigned at the time of the transfer) will receive the same label. This takes advantage of netfilter’s connection tracking features to allow ftp to only receive packets related to its connections. This requires no additional policy rules or policy modifications of any kind since the labels are all we are changing.

What this brings over netfilter’s existing functionality is the ability to specify precisely which domains can access which packets, so it allows you to bring the firewall functionality all the way to the processes rather than just to the machine, which is significant if you have several services of differing security properties running on the same machine. This would, for example, allow you to have an internal Apache instance with access to company confidential data to only be accessible internally and another external Apache instance that serves static web content to the internet.

While most people think of network access controls in the terms of firewalls alone this is not the only network support in SELinux. The next kind of SELinux network support is labeled networking.

There are two methods of labeling network traffic in SELinux: NetLabel, which is an implementation of CIPSO, and IPSec based labeling. I’m not going to talk about NetLabel because it only supports the MLS portion of the SELinux context and is primarily useful for making SELinux cooperate with legacy trusted operating systems like Trusted HP-UX and Trusted Solaris. IPSec based labeling sends the entire context but currently only works between SELinux systems.

As NetLabel is primarily for supporting MLS and legacy trusted systems I’m not going to talk about it, lets instead move to IPSec based labeling.

I’m going to assume some knowledge of IPSec here so if you are unfamiliar with some of the terms please consult IPSec documentation. In particular you need to know what SPD’s and SA’s are and what their role in IPSec is.
The first thing you need is a kernel that supports IPSec labeling. The easiest way (if you are using Red Hat) is to use the current Fedora rawhide kernel or the LSPP kernel. The LSPP kernel is available at http://people.redhat.com/sgrubb/files/lspp/. For the non-Red Hat users in the audience labeled IPSec is also available in the released version of linux-2.6.22.

You’ll also need an ipsec-tools that is capable of labeling, rawhides or the LSPP version will do here as well. Once you have everything you need installed you can start using labeled IPSec. We’ll start with simple labeled SA’s.

First I have a couple programs that will help test and ensure that everything is working. They are simple a simple client and server that connect, use getpeercon() to return what the context of the network socket is.

client.c

server.c

Build these by linking them against libselinux:

gcc -o client client.c -lselinux

gcc -o server server.c -lselinux

First lets try running them without IPSec to see what happens:

My test machines are 192.168.147.132 (scarecrow) and 192.168.147.130 (poisonivy), obviously replace with your addresses.

After running server on 192.168.147.132 and running client 192.168.147.132 on the other machine the output should look like this:

[root@poisonivy ~]# ./client 192.168.147.132

getpeercon: Protocol not available Received: Hello, (null) from (null)

[root@scarecrow ~]# ./server

getsockopt: Protocol not available server: got connection from 192.168.147.130, (null)

getpeercon() returns protocol not available because no labeling was enabled on this connection, you can use the error to determine if you are using a labeled network socket or not.

If we make an SA between these 2 machines without specifying a context we’ll get the same results:

[root@scarecrow ~]# cat dev/ipsec/setkey.scarecrow.test

spdflush;

flush;

spdadd 192.168.147.130 192.168.147.132 any

-P in ipsec esp/transport//require;

spdadd 192.168.147.132 192.168.147.130 any

-P out ipsec esp/transport//require;

[root@poisonivy ~]# cat dev/ipsec/setkey.poisonivy.test

spdflush;

flush;

spdadd 192.168.147.132 192.168.147.130 any

-P in ipsec esp/transport//require;

spdadd 192.168.147.130 192.168.147.132 any

-P out ipsec esp/transport//require;

Then run:

[root@poisonivy ~]# setkey -f dev/ipsec/setkey.poisonivy.test

[root@scarecrow ~]# setkey -f dev/ipsec/setkey.scarecrow.test

NOTE: both machines will need to be running racoon in order to create SA’s when the connections are attempted.

Running server and client the same as before will give the exact same results. You can use setkey -D to see the newly created SA’s. Notice that the SA’s are not be labeled.

If we add a -ctx statement to our setkey files such that:

[root@scarecrow ~]# cat dev/ipsec/setkey.scarecrow.test

spdflush;

flush;

spdadd 192.168.147.130 192.168.147.132 any

-ctx 1 1 "system_u:object_r:default_t:s0"

-P in ipsec esp/transport//require;

spdadd 192.168.147.132 192.168.147.130 any

-ctx 1 1 "system_u:object_r:default_t:s0"

-P out ipsec esp/transport//require;

You can use setkey -DP to see the SPD entries on each machine, note the context field in the entries.
Repeat this with the other machines setkey file. Note that you’d never use default_t in a label, this is an example to show what happens. This is _NOT_ the label that will be used to create SA’s, this label will be used in a ‘polmatch’ rule to see which SPD entries a domain can match to. This will be explained later.

Running setkey -f results in an error now:

[root@scarecrow ~]# setkey -f dev/ipsec/setkey.scarecrow.test

The result of line 8: Permission denied.

The result of line 14: Permission denied.

Looking for the denial:

[root@scarecrow ~]# tail /var/log/audit/audit.log | grep AVC

type=AVC msg=audit(1179150979.762:33): avc: denied { setcontext } for pid=21632 comm="setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=association type=AVC msg=audit(1179150979.895:34): avc: denied { setcontext } for pid=21632 comm="setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=association

This is good, it means that we can protect who sets the labels on IPSec SPD’s. For now set permissive mode on both machines and run setkey again, it should now succeed.

Run the client and server again and you should see something like this on the client side:

[root@poisonivy ~]# ./client 192.168.147.132

Received: Hello, root:system_r:unconfined_t:SystemLow-SystemHigh from root:system_r:unconfined_t:-SystemHigh

You can use setkey -D to see the newly created SA’s and note the context field in each entry.
Hopefully this image conveys how the SA’s are labeled, note that each side of the connection has 2 SA’s, one incoming and one outgoing with the appropriate labels. The outgoing SA for each system is always the local domain, the incoming SA for each system is always the remote domain.

I’d like to thank Chris Ashworth for the graphic, it is much simpler than mine and I think gives a better understanding of the labeled tunnels.

This demonstrates that the server sees root:system_r:unconfined_t:SystemLow-SystemHigh when it calls getpeercon() and the client sees root:system_r:unconfined_t:-SystemHigh. To show the difference more specifically run the client with a different context using runcon:

[root@poisonivy ~]# runcon -t httpd_t ./client 192.168.147.132

Received: Hello, root:system_r:httpd_t:SystemLow-SystemHigh from root:system_r:unconfined_t:-SystemHigh

Now you can see the server sees httpd_t when it calls getpeercon(). So now we’ve seen how you can identify the process context on the other side of a connection, but what about the policy?

Lets clear out dmesg and setenforce 1; setenforce 0; to clear the AVC and start the process over.

First running setkey and then audit2allow -d should show:

allow unconfined_t default_t:association setcontext;

This means that unconfined_t (what your shell normally runs as) tried to set the context of an association to default_t. This is expected since we used default_t in our SPD entry. Run dmesg -c to clear the kernel buffer and try to run the server and client (with runcon):

Removing the irrelevant rules we should see something like this on the client side:

allow httpd_t default_t:association polmatch;

This rule means that the client (running as httpd_t) attempted to match against the SPD entry we added earlier. This is useful because you can use SELinux policy to enforce which SPD entries a domain may match against. For example, if you wanted to have some domains use high quality encryption and let the others use a faster, lower quality encryption you can do that by specifying which SPD types a domain may polmatch against.

allow httpd_t self:association sendto;

This is httpd_t sending data to an association labeled httpd_t. This basically just means that it is sending to the association created for it. Note that with the current controls you can not control which domains you are sending to on the other side.

allow httpd_t unconfined_t:association recvfrom;

This is the most significant control; it says that we are allowing httpd_t to receive from an association labeled unconfined_t, which is the result of the server running in unconfined_t. This lets you use policy to determine which domains on another machine can send data to which domains on the local machine.

allow unconfined_t default_t:association polmatch;

And this is the remote domain (the server) matching against the income SPD entry on this machine. Note that there were 2 SPD entries added, one for outgoing communication and one for incoming communication, both domains have to polmatch the SPD’s on the local machine (for outgoing) and the remote machine (for incoming).

There should be similar denials on the server side, only reversed so I won’t go over those.

As you can see you can do a significant amount with this technology, assuming that you control both policies (source and destination) you can be very certain which domains are talking to which domains across machines, similar to the SELinux IPC controls but across a network!

For example, one possible application of this technology is to have an ‘internal’ and ‘external’ browser on employee workstations. The internal browser would run in a domain that is allowed to access internal company web application servers that contain confidential customer information while the external browser can access the internet. This reduces the risk that rogue internet content can compromise your internal data. This kind of separation would be much more difficult (or impossible) without SELinux’ advanced networking controls.

Using both labeled IPSec and netfilter secmark you can do some pretty amazing things with SELinux networking, and its only going to get better, stay tuned for more information.

A special thanks goes out to all the people that worked hard on getting this technology where it is now and the same ones trying to push it even further to have the best secure networking infrastructure around. These people include (in no particular order): James Morris, Venkat Yekkirala, Joy Latten, Paul Moore (who implemented NetLabel), and many others.

I’ve been asked if I think many people would pay to take an online shorter version of the class if it were around $500. I wasn’t sure how to answer so I decided to ask the people that read my blog what they think. It would be an 8 hour video or slide version of the course available on the web. If not many people would take the class another option is to have a 1 hour free webinar that talks about how SELinux can be useful to commercial enterprises that IT people could use to learn some basics about what SELinux can do.

I’d like some feedback on these ideas but in any case you can come see me teach a tutorial in person at Linux World Expo - San Francisco in August.

As you (hopefully) know in my day job I work on the SELinux policy server, which as far as I know, is the most forward looking SELinux project around. Granted all those forward looking goals aren’t published on the site, hopefully we can remedy that at some point.. So alot of this is going to be centered around the policy server, other parts are just on my wishlist.. without further ado lets get started…

I think the absolute most important thing that needs to happen is that SELinux needs to become part of the system, not a strap on, not a value add, not an extra burden, it must be part of the system. There are a ton of things that need to happen for that to happen, most of the desires below will, in some way, reflect on this main goal.

First and foremost we need complete protection. Its been said many times in the past and its still true. If SELinux desktop deployments are ever going to be entirely secure a security enhanced X server is necessary. Without it even a confined mail client or web browser can use the X protocol to manipulate or otherwise hijack other applications running in X. This isn’t something that can be solved any way except by making X an object manager. This work has been done, I personally have run a security enhanced X server for extended periods of time but without a proper integration into upstream and proper deployment by distributions it won’t help. In addition to the enhanced X server the window manager must be SELinux aware. This means that the window manager is capable of launching applications in different domains, managing clipboard data and ensuring it doesn’t allow information to be leaked from one domain to another without permission and many other things. Once these two things are in place we are well on our way toward SELinux utopia.

One of my biggest desires is to use SELinux to its potential and make the root user powerless by default. Ubuntu has started on this path already, making the root user not able to login and forcing users to use sudo to do administrative tasks. This is a disruptive concept that many many people won’t like but it must happen. Once the root user is powerless by default SELinux roles are used to manage administrative tasks and grant only what is necessary to each user, which brings me to my next point.

Fine grained role management is an absolute must. The SELinux reference policy already has concepts that will allow this to be implemented in the (hopefully) near future. Each policy module should export some sort of role capabilities (not to be confused with Linux or POSIX capabilities) that can be granted by the system administrator. For example, the Apache module should have an interface that, when invoked, gives a role authorization to administer Apache, whatever that means. Once the policy is running on the system the administrator should be able to specify the precise capabilities that any role is able to use. This brings me to my next point.

The user management and selinux role and user management must be unified. An administrator should absolutely not need to go to a different application or dialog box to give a user that he just created extra SELinux privileges. SELinux must be a first class citizen of the system. In the user management interface the SELinux options must be present and easily usable. For example, my small company just hired a new junior admin. I want this admin to administer a handful of daemons, including apache. The interface where I create him as a user should have a very obvious way of customizing his roles capabilities (this depends on the fine grained role management). Everything about the system must be unified, which, again, is my main point, SELinux must be part of the system, not an addon.

When I want to adjust my firewall settings SELinux settings should be present. We already know that SELinux is capable of much more fine grained network controls, specifically that you can specify specific domains that can access the network in specific ways. The example I want to use here is Firefox.  I want my enterprise to enforce that each workstation must have two web browsers, one that is intranet only and one that is internet. This will allow me to prevent any kind of Firefox exploit from touching my internal network. The network management should be able to let me specify that I want two Firefox domains with different network access controls. We’ll put two firefox icons on the desktops and SELinux will take care of the rest.

We shouldn’t just have fine grained access of client sessions though. One of the biggest problems plaguing the Internet is that web servers are notoriously insecure. When a random untrusted user’s PHP scripts are allowed to run in the same domain as trusted system scripts there is clearly a problem. Apache should be able to bracket privileges of user and system scripts, or even fine grained bracketing between different classes of users. The most secure and effective way to do this is to execute interpreters per target domain. FastCGI basically does this for DAC already. When a user’s script is accessed FastCGI determines if there is already an interpreter running as that UID that can handle the request, if not it will spawn one. We need to take this one step further and make a system like FastCGI spawn interpreters per UID per domain. This would make an enormous difference in the security of webservers and should be the default configuration. Alternatively for people who truly have performance requirements Apache chould use dynamic transitions to bracket privileges, though I don’t suggest this as a permanent mode of operation.

Speaking of privilege bracketing, it would be very nice for other applications to do this as well. The systems package manager (we’ll assume RPM for now) should be able to do a few things. The proper RPM process will have access to do pretty much anything, thats a given. That doesn’t mean, for example, that arbitrary scripts that execute as part of the install process should have unlimited access to the system. RPM is already able to execute scriptlets in a different domain so we are partially there. One interesting thing I’d like to see is RPM being able to treat ‘trusted’ and ‘untrusted’ packages differently. We’ll assume packages coming from the distro are trusted and third party ones are untrusted. An untrusted RPM should be much more restricted on the system, both the scriptlets and the RPM process itself. An untrusted application shouldn’t be able to overwrite high integrity binaries or configuration files (think /usr/bin/passwd and /etc/shadow) or label files with high integrity labels (like passwd_exec_t). Firther the scriptlets should not be able to overwrite files on the filesystem or any of the other nasty things scriptlets like to do. This is disruptive as well since there are probably about a million RPM packages around that do seriously questionable things.

Since RPM also installs SELinux policy the same bracketing should apply there. Using the policy server one should be able to restrict the kind of policy an untrusted RPM can insert (while still allowing them to insert policy for the application being installed). For example a third party RPM like Opera (hypothetically ofcourse) should be able to install the browser policy but should not be able to add rules that let it (or anything else for that matter) access /etc/shadow. Nor should be allowed to overwrite any system binaries or libraries. A production ready policy server (we are working on this, I promise ) and an effective metapolicy would be necessary for this requirement.

Since one of the most critisized aspects of SELinux is its inability to apply fine grained controls to network filesystem this should also be added. This is alot more complicated than it seems at first, the network protocol should be sufficiently protected enough that the file labels sent across can be trusted. The client and server must also agree on an access control policy otherwise unexpected things can result. The client won’t be able to subvert the policy on the server side but since many network filesystems are caching the user might not understand why a write succeeds but is reverted when the client flushes its cache to the server. Network security servers like Samba should be able to take advantage of SELinux by applying access controls to the incoming clients.

SELinux management, up until now, has been very focused on the policy itself. This isn’t how administrators or users think, however. If someone wants to give user bill write access to a file in /usr/local/bin/bills-script he won’t think to go to a policy, he’ll instinctualy go to either the object itself (/usr/local/bin/bills-script) or to bill in the user manager. Either interface should be able to manage SELinux permissions. Chances are most people aren’t going to learn how to write SELinux policy (most people didn’t learn how to write sendmail.cf files and look what happened there!). Simple permission assignments like this should be taken care of by the SELinux management tools, and should be transparent (why do they care what needs to be done to give access, they just need it).

This solves some problems but most applications written are applications run within an organization which means there are going to be alot of applications running on SELinux systems that no policy developer has ever seen, or ever will. The process of writing a policy for these applications must be made significantly easier. I’ve posted about how bad status quo encapsulation is in the past but at this juncture an application running a status quo style policy is better than it running without one at all. The system should be able to write a policy for the application with very little interaction from the administrator. This will always leave the ability for more savy admins and users to write well thought out policies for their applications but we need an 80% way to write policies that will help the vast majority of people.

SETroubleshoot is a very good first step toward a widely usable SELinux but it needs to go even further. More targets need to be written for it so that it understands most denials. If most expected denials can be caught and dealt with the remaining denials may be indicative of an actual problem on the system, like an attack, something that an administrator should be notified of. By eliminating as many false positive denials as possible SELinux auditing could become useful as an early warning system for attempted intrusions and other bad things.

One of the most important things that SELinux can do is educate software developers and companies that their software is broken and how they can fix it. I allude to this in another blog article but this will be the most help to the most people. If most systems are running SELinux and users tell vendors that disabling it isn’t an option that will force them to fix their software for the betterment of all of their users. I hope that this will be one of the most significant impacts SELinux can make on the entire industry for opensource applications, commercial applications and even internal applications.

Oh, one more thing, we need a really cool and secure looking framebuffer graphic that is shown during bootup, that way people know we are really secure

That said, I taught an SELinux tutorial at LWE San Francisco last week, unfortunately my tutorial wasn’t one of the ones reviewed by the media, what a shame. During the tutorial I was asked about AppArmor, to which I said they could come up after the tutorial to talk about it, I didn’t want to disparage it in front of an audience of 50, I’m a nice guy like that.

Then I saw this article, which has a quite humorous title, which prompted me to go ahead and write up something that I can point to in the future.

If you’ve read my previous articles you’ll see the great deal of technical problems AppArmor has and I can even add a few such as an incomplete reference validation mechanism, incomplete object model, the fact that it isn’t really mandatory access control (and thus not even comparable to SELinux), etc. Those don’t seem to affect a large number of people though, decision makers and administrators sort of give me strange looks when I start going into those.

So here are some more reasons, slightly less technical but probably much more important to these particular crowds. You see, I was an admin once upon a time and speaking from experience admins are much less likely to take a ‘purity’ argument seriously, because they know the kind of impure crap that has to happen to get the job done.

I think the most important and compelling argument for both of these crowds is one of scalability. AppArmor is very much a ‘right now’ type of solution. They give you exactly what you see, a security mechanism that will protect some of your applications within a limited threat model, namely only remote intruders and only if they can only exploit 1 application. So, you say that’s all you need and AppArmor lets you write “profiles” in 5 minutes? That’s great, are you sure it is all you will ever need?

With AppArmor there is no room for improvement. The authors were so focused on ease-of-use that they pushed all the simplicity into the model (incidentally this often creates a very complex implementation but that is another point). The model, then, only covers this very limited threat model. You will never be able to secure your infrastructure more than you can today with AppArmor. Your system level applications will never be secured, your users will never be restricted, and your confined applications only haphazardly.

SELinux has its roots in research that started around 1992, to build very secure systems on OS’s like Distrubuted Trusted Mach (DTMach), which later continued as the Distrubuted Trusted Operating System project. Eventually the Flask architecture comes out of an implementation by the NSA and the University of Utah which is the same architecture that SELinux uses today. When I started working on SELinux 4-5 years ago it was a very very hard thing to use and implement in a distro. The SELinux researchers and developers were very interested in getting the security right, and then simplifying it with tools in userspace, like it should be.

So here it is, 2 years after Red Hat first put SELinux on by default in a general purpose distro (oh yea, AppArmor also doesn’t come on by default) and the usability of SELinux has leaped lightyears ahead of where it was. The best part is that SELinux will continue to get easier, while keeping its strengths while AppArmor was artificially limited by a broken design.

So, that’s the background on SELinux. The point of it was to say, SELinux is complete and comprehensive and also very flexible. The SELinux policy lets you basically accomplish any kind of security goals you have. So you can deploy SELinux today using the targeted policy and tweaking where necessary on your system, which requires little SELinux expertise and when you are ready you can secure more and more of your infrastructure, you aren’t artificially limited, SELinux scales to any security goals you might come up with anytime in the future.

So I believe that is a pretty compelling reason for an Admin, but I’ll throw in another bonus reason. AppArmor claims extreme ease of use and Novell is pushing it on their enterprise clients but one important thing they are missing for any enterprise is any kind of network policy management. I’ll grant you that SELinux isn’t overflowing with network policy management capabilities today but there are several works in progress. Even without the specific network management SELinux has modular policy and local customizations that let you maintain a set of policy modules that you can deploy to your systems while maintaining local customizations on top of those policies at each machine that needs them, already significantly better than any AppArmor offering. My employer, Tresys has a product coming out called Brickwall that has some pretty advanced network management capabilities and obviously my project, the policy server, has some crazy capabilities extending even to access control on the policy, so that you can delegate parts of the policy to junior administrators without letting the intent of the policy change.

With the scalability and management features of SELinux (and the lack of them in AppArmor) I’d be seriously shocked if an informed administrator chose AppArmor.

Once upon a time the SELinux policy compiler was a simple creature. It was self-contained and merely translated source rules into the binary policy in a fairly 1:1 fashion. It became apparent that this kind of policy was difficult to use on complicated systems like Linux and conveniences like attributes were added. The compiler was still simple but had the potential of converting one source rule into many rules in the binary. This is about the time I started working on SELinux, back in early 2003. This worked out fine for a while, as long as users had the policy source on their machines in order to do any kind of customizations at all to the policy (including fairly simple things like adding users). Clearly Hardened Gentoo was fine with this since we compile everything from scratch anyway. Red Hat, however, didn’t share our sentiment. Soon after Red Hat did their initial integration work in 2004 the need to make modifications to the policy on production machines became clear. The initial extent was small, only users could be added to the policy and Booleans could be made persistent (lasting across reboots). This required much of the policy infrastructure to be factored out into a library called libsepol. The compiler now links statically against libsepol to build up the policydb structure (the structure that the entire policy is stored in) and other applications can link against libsepol to do operations on the binary policy as well. Originally init and load_policy were modified to read a file with users and a file with Boolean settings and apply them to the policy before loading it into the kernel. The customizations specified in these files never were written to the policy on the disk.

While this was a useful progression and necessary for Red Hat’s integration there were some concerns about mutating the policy in memory before loading it (and never having a copy of the mutated policy on disk to analyze). The initial customizations wouldn’t have affected analysis much but there were some concerns of a slippery slope and it couldn’t be long before people would want to add rules to the policy without having the source around.

At the same time all of this was going on I had started working at Tresys and one of my first projects was to implement loadable policy modules. We went through several different designs and finally ended up with what you see today, for better or worse. The current module implementation has some limitations, some that we plan to address such as interfaces being part of the language, but are now in pretty good working order for the upcoming FC6 and RHEL5 releases. Now that modular systems are going to be deployed in released systems I hope to educate people about what they are and how they work. So, now that all the history is out of the way lets get dirty.

All policies are stored in a struct called policydb which is defined in libsepol/include/sepol/policydb/policydb.h. A simplified version of the struct looks like this:

struct policydb {
    policy_type;  /* specifies whether this is a base, module or kernel policy */
    symtabs;    /* hashtables of symbols including types, classes, roles, etc */

    indexes;    /* various indexes used during processing and compiling */

    /* --- Stuff only in modules (base or module) -- */
    name;       /* name of module (only used for modules) */
    version;    /* version of module (only for modules) */

    scope_tables; /* tables that tell the scope of each symbol, what optionals
           * they were declared in or required in */

    avrules;    /* linked list of rule blocks, one for the global scope of a
         * module and one for each optional block in the module. Avrule
         * blocks contain everything  that can be in an optional such as
         * symbol declarations, allow rules, role allows, and conditionals
         */      

    /* -- Stuff only in kernel policy -- */

    avtab;  /* hash table of rules, keyed on source type value, target type
         * value,class value and rule type (allow, dontaudit, auditallow)
         */      

    role_trans; /* role transition rules */
    role_allow; /* role allow rules */

    /* -- Stuff only in kernel and base -- */

    ocontexts;  /* other contexts like ports, nodes, initial sids, etc */
    genfs;      /* genfs contexts like /proc */
};

So now that the policy format is as clear as mud we can go into some of the specifics. You’ll note that, although the module, base and kernel formats are slightly different, they all share the same struct. This was done for simplicity sake since there is significant overlap and code reproduction for multiple structs would have been much harder to maintain.The most notable difference between the modular/base and kernel formats is that they serve a different purpose. The kernel format has an efficient way to look up access vectors (allowed permissions) for any given source, target, class: hash the values and do an O(1) hashtable lookup (for now we’ll ignore the version 20 changes). The module format, on the other hand, can’t easily look up an access vector. The module format, however, stores something that is much more representative of the original rule that was in the source code (we’ll call this the symbolic representation from now on). For example, consider a rule like this in the source:

allow portage_t { file_type -shadow_t }:file { read getattr lock ioctl };

This rule says that the domain type portage_t can read, getattr, lock and ioctl all file objects in the file_type attribute (which is all of them) except shadow_t. In the kernel format this rule would expand to a rule for each type in file_type (which is often over 1000) except shadow_t. The purpose for this type of expansion is so that when the kernel security server receives a request for portage_t to, say, etc_t with the file object class and the permission read it can simply hash the value of portage_t , etc_t, file and get the corresponding set of allowed permissions. This is ideal from the enforcement point of view but we needed something different from rules.

The modules needed to maintain what the source says, specifically the { file_type –shadow_t } part. This is because from within a module the final meaning of file_type would not be known. No single module has a full picture of the entire policy and therefore no module can determine what the expanded set of rules for this single source rule would be. Further more complex things like subtracting an attribute require us to carefully preserve what the source says, included deprecated syntaxes like * and ~ in the type fields.

So, in the modular format a rule is stored individually (and potentially redundantly) in a struct that looks like this:

struct avrule {
    rule_type;          /* the kind of rule, allow, dontaudit, neverallow, etc */
    type_set source;    /* set of source types */
    type_set target;    /* set of target types */
    class_perm_list;    /* linked list of classes and permissions */
}

struct type_set {
        types;  /* ebitmap of all types specified */
        negset; /* ebitmap of all types negated */
        flags;  /* whether * or ~ were used */
}

Using these structs we can specify the above rule fairly easily. The source type_set would have only portage_t in the types ebitmap and the target would have file_type in the types and shadow_t in the negset. The class_perm_list preserves all the classes and * and ~ for permissions.

The main difference between a kernel policy and a base module is the rules, as shown above, the other fields are mostly the same. A policy module is a subset of a base module in that it cannot have any kind of labeling (such as filesystem or networking). The policy modules also do not support MLS yet so all MLS related stuff (level and category definitions, range transitions and users with mls levels) must be in the base.

Hopefully at this point you’ll have a good idea what modules are for and how they are different from the policy loaded into the kernel so I’ll continue by explaining how it is that modules work their way to becoming a policy that can be loaded into the kernel.

First a graphical representation of the linking, the modules are copied into the base policy:

I’m not sure how obvious this image is but hopefully it shows the portage symbols (eg., portage types) being copied into the base policy symbol tables (and the type values change since the base will probably have types with the same values as the portage module so the maps are set up to know what value a type had in its module and what the corresponding value is in base). Next the avrule blocks get copied into the base. They are linked into the list of avrule blocks already there. The same thing happens with the apache module. This new base (or linked copy) is then a superset of base and all the modules. All the symbols from the modules have new (unique) values in base so when the rules are copied the new mapped values must be used. There is quite a bit of technical detail about the copying that I’ll just skim over here, if anyone is interested let me know and I can write something more in depth later.

After all the avrule blocks have been copied to the base the dependency checker is run. Each module declares its symbol dependencies explicitly. This means that if the portage module needs to use file_type and shadow_t (as in the earlier rule) those types and attributes must be explicitly requested in require { } blocks. Note: in reference policy require blocks are not seen in .te files since the interfaces that use symbols always request them before using them. Optional blocks also have require { } blocks to determine whether that optional block will be enabled.

The dependency algorithm enables all optional blocks and then loops through them determining if the symbols required by those blocks are satisfied. When the requirements are found to be unsatisfied the block in question is disabled and the loop continues. If a global block (which is the unconditional part of each module) is ever disabled the dependency checker will immediately bail and tell the user that the requirements for that module were not met. The global block in the base module is self contained and may not have any require { } blocks.

Once we have decided which blocks are enabled and marked them thusly we are done with the link phase and are ready to send the linked policy to the expander. The expander is fairly simple in theory but in practice a lot of stuff has to be done to ensure the policy is correctly created. When the expander is called two policydb’s are passed in, the linked copy and a brand new empty copy. The expansion is done into a fresh policydb for simplicity so that no cruft is left in from the linked copy which has much more information (such as every symbol, whether it turns out to be disabled or not).

The expander starts by going through each symbol table and copying over only the symbols that are enabled. The symbols are mapped to new values so that there are no values left unused in the resulting policy which would cause the policy to be bigger with no advantage whatsoever. Once all the enabled symbols are copied over the avrule blocks are looped through, first the rules are expanded from the symbolic representation into the avtab (a hashtable that holds all the rules, keyed on the source type, target type, class value and rule type). The datum of that hashtable is simply a 32 bit bitmap of the allowed permissions. The avrule blocks also hold “additive” symbols, which are symbols that have a list of something in the datum. The additive symbols are attributes (which have a list of types), roles (which have a list of types, and users (which have a list of roles). If the avrule block is enabled the additive symbol datums are OR’d into the main symbol table of the expanded copy. For example, if an avrule block has a line like:

typeattribute portage_t file_type;

then portage_t is added to the datum of file_type in the expanded copy. Once all the avrule blocks have been evaluated all the rules and the additive symbols are complete. The expanded copy is now a valid policy loadable by the kernel. One last thing has to be done, the linked copy holds neverallows in the symbolic form. Tthese neverallows are copied into the expanded copy in the same form (and later discarded) and are used to determine if the final expanded policy violates any of these rules. If no neverallow assertions have been violated the hierarchy checker is run. The hierarchy checker is a validation stage introduced for the policy server which enforces the idea that a hierarchal type (like portage_t.merge, the portage type used for merging files onto the filesystem) cannot have more permissions than the parent type (portage_t in this example). I can go into the details and purpose of hierarchal namespaces in another article.

After these post-checks are done the policy is ready to be written to disk and loaded into the kernel. The mechanism described here is what happens in libsepol from modules to a kernel policy, in practice libsemanage, the new library that manages policies on FC5 and RHEL5 systems handle all of this and also does some other policy manipulations. I’ll can also talk about these another time.

So that is how SELinux policy modules work in a nutshell. Hope this helps anyone interested in this particular subject.