Brindle on Security

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

Its been a while since my last post, I apologize but I have a good reason I promise . I’ve been busy working on a series of patches to make the SELinux policy compiler and libraries much more stable and robust and to make optional blocks in the base policy work correctly. While the libraries and compiler are fresh on my mind I thought I’d go ahead and write an article on how the SELinux policy modules work.

Read the rest of this entry