Tag Selinux

On AppArmor

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.

SELinux Policy Module Primer

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.

Trusted what?

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.

Software not working? Disable SELinux.

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).

Security Anti-Pattern: Path based access control

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.

Top-down vs. Bottom-up Policy Development

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.

Security Anti-Pattern: Status Quo Encapsulation

First a clarification: in my last post I said that least privilege is the ultimate goal of most MAC advocates but that isn’t entirely true, I accidentally ignored a large portion of MAC advocates (mostly those that predate me!). There are several different models which are commonly implemented and thought to be correct. In the government industry that model is Multi Level Security (MLS) and is in no way least privilege, but that is another topic altogether. In the civilian sector status quo encapsulation is a popular model to implement, which is what I’ll be talking about today.

The Myth of Least Privilege (or why we love equivalence classes)

Just about any Mandatory Access Control (MAC) advocate will tell you that their ultimate security goal is least privilege. Least privilege has become a metaphorical holy grail in the security industry. Least privilege, in its unadulterated form is giving each user, process and so on the exact access it needs and no more.

Welcome to Brindle on Security

I’ll start this blog by introducing myself. My name is Joshua Brindle and I’ve been working on security software and such for a while. About 4 years ago I started Hardened Gentoo which exposed both myself and many users to modern security systems available for Linux. This project has, in many ways, led me up to where I am today in my career and otherwise. Today I work at Tresys Technology on research and development on security systems.