Brindle on Security

This article was requested, and was a long time coming anyway.

I’ve gone over Multi-Level Security (MLS) a little bit before. It’s basically a security policy that is implemented by many trusted operating systems (such as Trusted Solaris) that is hierarchical and inflexible by nature. Specifically Bell-LaPadula (BLP) is used by many operating systems because it reflects the real world security policy used by the government and military. In BLP subjects and objects have a label consisting of a level (Secret, Top Secret, Unclassified, etc) and a set of non-hierarchical categories (US Only, Army, etc).

The sensitivies are hierarchical in that a higher sensitivity process labeled top secret can read and write top secret objects but only read unclassified objects. This prevents the ‘downgrade’ of classified information. For systems that conform to this kind of policy it makes perfect sense, a multi-level desktop system allows users to keep top secret and unclassified material on the same system but does not allow the release of top secret data to unclassified environments or users. Lower levels can also write to higher levels, in some cases. This may seem bad but considering what the policy is trying to accomplish allowing an unclassified process to write a top secret document doesn’t disclose top secret data. The catch is that the unclassified process would never be able to read the document after writing it. This policy is only usable for confidentiality, to prevent information from being released inappropriately. It cannot address integrity or other security goals I have mentioned in other articles.

Because traditional trusted operating systems only implemented BLP (and in some rare cases Biba for integrity) the users of such systems (primarily government and military) had to use it even when it wasn’t appropriate. One such case is a guard, or cross domain solution (CDS). A CDS is a system that allows two or more networks of differing security properties to be connected to one another. A typical CDS can connect a top secret to a secret network, for example, and allow information from the secret network onto the top secret network but not vice versa. CDS’s also do the opposite, allowing a controlled release of information from top secret to secret, or between two coalition networks (Such as Australia and the US). CDS’s always have some safety mechanism built in to prevent malicious data, or inappropriate data from going across it (if it didn’t it wouldn’t be any more useful than a crossover cable between the networks). These safety mechanisms are virus scanners, “dirty word” filters, document disassemblers (for example to take a word document and convert it to plain text or pdf), etc. The type of safety mechanism primarily depends on what kinds of networks the system is connecting.

For now we’ll talk about the first case, letting information flow from a secret network to a top secret network. Since a BLP system is designed to let information go from secret to top secret already it seems like an obvious fit, right? If the CDS was a very simple system with a process to read incoming data, a virus filter and an outgoing process it seems like a BLP policy would be fine. We are going to call the set of processes that pass data through the system the pipeline.

Wrong, there are actually multiple issues here. Because the lower levels would be allowed to write to higher levels, but not read from them we could label the incoming process Unclassified, the middle process Secret and the outgoing process Top Secret. This allows flow from the incoming process to the outgoing process. The main problem here is that since the levels are hierarchical there is nothing that stops the Unclassified process from writing directly to the Top Secret process (oops). Well, people figured this out and thought of a great work-around. Remember those categories? Categories allow reading and writing when the subject dominates (or has a superset) the categories of the object. So you give the incoming process categories that dominate the categories of the middle process but not the outgoing process.

So that problem is solved (albeit in an interesting way) but CDS’s are never that simple (I mean never). The requirements that are imposed on CDS’s specify pesky little things like logging, auditing, monitoring, emergency shutdown, etc. So now our simple CDS needs all processes to be able to talk to a logging system, and a monitoring system must ask the processes for their state and get back a response. So now we have one or more huge processes that can talk to and receive data from every process in the pipeline. That wouldn’t be so bad except the functional requirements of every guard I’ve seen says that those logs have to end up on the high side for consumption, which is obvious, they certainly can’t go to the low side because that would be a violation of the security policy. This, of course, allows information to flow through the logging and monitoring process out the other side without going through the set of filters. Sure, the advocates will say the logging and monitoring system is part of the TCB (Trusted Computing Base), the part of the system that is trusted to not do nasty things, but in a system like this do you want such processes to be trusted?

The above (totally professionally done) diagram shows the attack vector that would be used to get data through such a system. Because the logging/monitoring app is allowed to violate the MAC policy it is possible to use it to bypass filters 2, 3 and 4.

So basically its impossible to use a BLP policy on a guard and ensure that all data is passed through all filters before it reaches the other side, the policy simply wasn’t made for that kind of thing. It has been the standard operating procedure to shoehorn CDS’s into that policy for a very long time, however.

Before I get into how SELinux helps this I’ll quickly cover the other two types of guards I previously mentioned. First the High-to-Low guard. This kind of guard basically allows controlled downgrading of information; it will run filters like a ‘dirty word’ filter to ensure nothing that shouldn’t be getting downgraded isn’t. It may also redact some data. This CDS is a direct violation of the BLP policy, as such the processes essentially have to be MAC Exempt, or not subject to the policy, essentially making the existence of the policy irrelevant, it should be easy to see why this is an inappropriate use of BLP. The second was a CDS between two coalition partners. In this case the BLP policy doesn’t even mean anything since there is no high side and low side, merely ‘different’ sides.

So, those are the reasons why BLP is inappropriate for CDS’s, why is SELinux different?

SELinux primarily uses type enforcement for policy decisions. Type enforcement allows fine grained policy to be written for all subjects and objects on the system. In the case of CDS’s you can literally say incoming process can write to virus scanner (but not read) and virus scanner can write to outgoing process. We call this an assured pipeline. This can be used for any size or type of pipeline, we even have a tool called CDS Framework that lets you visualize the CDS system. But wait, what about all that logging and auditing and monitoring? Simple, since the policy can describe arbitrary relationships between processes we can break that logging and monitoring process up into filter size chunks, then allow each filter to read and write from the logging and monitoring app. The logging and monitoring app can then send its logs through the same pipeline as the data, it will end up on the high side but there is no additional large process you have to trust to allow it to happen. Using type enforcement we can ensure that every single bit of information that comes leaves the guard passed through every filter (we can’t, of course guarantee that the filters worked). Since type enforcement is not hierarchical the direction of the CDS doesn’t matter, we can do the same thing for High-to-Low that we do for Low-to-High, or even between coalition networks.

The above diagram shows a possible CDS configuration using type enforcement. It allows for logging and monitoring and simply passes those messages back through the filters to get them to the high side. In this configuration no single part of the pipeline is trusted to violate the policy, and filters can never be bypassed. This policy would be impossible to enforce with BLP.

Don’t take this to mean that I hate MLS and never think it’s useful. I’m not saying it kicks puppies (although it does occasional pee on rugs I’m told). MLS has a time and a place, just like everything else. The point I’m trying to make is that it shouldn’t be used if it isn’t appropriate, as has been done in the past (and continues to be done today).

Recently I was looking around for a piece of software and I thought to myself “I need something with a more liberal license than the GPL”.. Then I thought “Wait, is liberal the right word there? Hrm”…
So what do you guys think?

No, seriously. I’m not trying to be ironic because the title of my blog is “Brindle on Security”, which I should probably change to something more creative anyway.

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.
Read the rest of this entry

Now that Blu-Ray has all but won the HD format war I guess its a little late to post this but oh well, I’ll do it anyway.

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.

Read the rest of this entry

I just got a comment on my post about path based access control that was fairly startling to me. The more I thought about it, though, the more I thought maybe others shared the beliefs so I’m going to respond to it here.

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.

During the last year quite a bit of effort has gone into improving SELinux’ networking support, thanks to the great SELinux community. While this support is still evolving it will be very beneficial for people to try it out and give feedback so the final result is useful to more users and meets the security needs of a wider audience. As the network support in SELinux continues to evolve (there are already other ideas being discussed for possible inclusion) I’ll try to keep this post updated so that people who find it will have the latest information available.

Read the rest of this entry

A while back I wrote a post on companies telling their customers to disable SELinux in order to get applications running and why this is a very bad thing. While I don’t see the situation getting better in the near term I did see a blog posting today from an SAP employee about using SELinux with SAP. This made me happy

Since I don’t think his blog software uses trackbacks I’ll be contacting him to suggest some changes. Namely he says that SAP would not be able to send SELinux policy modules with their software to customers since it apparently gets installed in many different places.

I’d first like to mention to him (and anyone else reading this) that SELinux policy does not care about paths, only types. The policy part of the module can be the same for every SAP customer, specifying the exact interactions between their software and the rest of the system. The file context part of the module is not compiled and can be generated at install time and added to the policy they distribute with the semodule_package command. After installing the module and labeling the SAP related files everything should work the same.

Next I’d like to mention that, while this is a noble effort and I’m very happy to see enterprise vendors showing their customers how they can use SELinux, this article essentially tells people to audit2allow the SAP related denials into policy without reviewing exactly what those denials were or whether they were appropriate. My status quo encapsulation article is an analysis of this style of policy writing and why it is bad.

If a SAP engineer wanted to create a policy for SAP applications that implemented proper security objectives and have that added to the reference policy I’m sure we’d be more than happy to add it in. There are other options though. IBM has been working with my company, Tresys, to develop a product, Razor, that takes generates policy for Websphere and DB2 by using configuration files that are understandable by the administrators of said applications. More information on the technique that Razor uses to create policies is available in a case study from the 2006 SELinux Symposium. This product can be used to generate policy for all kinds of enterprise applications, including presumably SAP, that implement specific security goals instead of just encapsulating the status quo of the application.

All that said, I’m still glad to see some companies taking initiative and trying to work with their customers instead of against them.

My employer, Tresys Technology, occasionally hosts an SELinux training class, many of which I’ve been the teacher for. The course outline and slides are available for free at http://tresys.com/selinux/selinux-course-outline.html but that isn’t what this post is about.

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.

I’ve been talking to a few people about what SELinux might look like in a few years and the conversations have been fairly stimulating so I’m going to share some of the ideas here.

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…
Read the rest of this entry

This will be the last thing I write about AppArmor because quite honestly it’s a waste of time to constantly refute people and I’d rather work to make security better for everyone :).

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.

Read the rest of this entry