Brindle on Security

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

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.

Read the rest of this entry

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.

Read the rest of this entry