Brindle on Security

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

This is a response to an open letter from Darren Moffat to IBM. While this open letter has very little substance and is almost entirely opinion there are some things I’d like to address.
Read the rest of this entry

So, this is a break from my normal philosophical theme to talk about a real experience I had this week.

Basically I was trying out some software, without saying what it was or who makes it, I thought it might be helpful for the software development I do at work. For those who don’t know I work on SELinux libraries and the policy toolchain at work.

That said, I downloaded the trial version of the software and got to work. The first time I ran it I got a very obscure error, it had to do with how the app was being run (after installing it according to the instructions included). After figuring out the “correct” way to run it I started it up only to get another (more obscure) error. I emailed the support address found on their page, including strace outputs and a description of what happened with both issues.

I got an email from who I originally thought was a low level support staffer who was instructed to say this, but is actually a cofounder of the company. The email read:

Hi Joshua,

I think you may have selinux enabled (FC5 has this by default).

If /etc/selinux/config has the line:

SELINUX=enforcing

then you need to change it to:

SELINUX=disabled

(or permissive should work, although I’ve not tried it).

Unfortunately, you need to reboot for the changes to take effect.

Hope this works for you (if not, please don’t hesitate to ask).

Read the rest of this entry

For those of you who missed my other Security Anti-Pattern post, an anti-pattern is a commonly reinvented bad solution to a problem. There are many of these in security but one that seems to be occurring quite often these days is path based access control, an access control system that use file paths to refer to objects. To the uninitiated this may seem like a good idea at first, hopefully this blog entry will eradicate such beliefs. Apologies in advance for the length of this post.

Read the rest of this entry

I’ll be the first to say I’m not a policy developer. The process of actually writing policy is not at all interesting to me, fortunately for me there are people like Chris PeBenito, Russell Coker, et al that seem to enjoy this. I am interested, however, in how policies are developed.

There seem to be two schools of thought on this subject: top-down policy development and bottom-up. Top-down policy development is very similar to status quo encapsulation, which I talked about in a previous post, in that it basically means you take a running system and look at it top-down, in its entirety, and develop a policy based on that perspective. Bottom-up policy development, which is historically what SELinux has done, is the opposite; you create policies for individual applications running on a system until the sum of those policies meets the security goals of the system. I’ll try to talk about the advantages and issues with each of these.

Read the rest of this entry