jcm's blog

So today, I allowed my laptop to upgrade to the latest F9 packages. Shortly afterward, VPNC could no longer run its connection script to connect to my corporate VPN connection.

I looked for an AVC denial message in my GNOME notification area (it was only later that I’d be paranoid and check that the sealert and friends were actually being allowed to run, which they were), but there was none. And none of the system logs readily showed any SELinux problem, so I decided it wasn’t time to Just Blame SELinux. A half hour of hacking at the VPNC script later, and getting confused why the commands within that script would run via sudo but didn’t seem to be running when called by VPNC, and I had myself an answer. Obviously it must be SELinux at fault, somehow, somewhere, sometime.

Calling setenforce 0 before running VPNC results in no errors and the VPN comes up just fine, whereas turning SELinux back on immediately results in a failure to run the connection script. The RPM itself reports context information that is consistent with that on the actual files, and again, there are no denial messages being reported – running sealert manually would seem to confirm this, and there are no messages in obvious log files. So it comes down to this: something is broken in F9, I can’t yet determine where it is, but a simple update has resulted in SELinux causing yet more pain that it’s ever possibly worth.

I’ve almost learned my lesson. I listened to certain people when they suggested that using SELinux was a great idea, and that doing this on F9 is super cool because it wouldn’t get in the way, and that it’s all great because we can protect ourselves from ourselves and our own evil actions. But all these people have forgotten one minor point – SELinux policy is so complex and/that we get these random failures. This is a highly undesirable user experience for a desktop. I’m about ready, once again, to hurtle SELinux out of the window as far as humanly possible. Way too overly intrusive to be actually useful.

Yes, I’m sure there’s a BZ somewhere, and I could just wait for another set of package updates that I’m sure will resynchronize policy with package, but let’s please notice that in the meantime, Joe User has long since given up and gone out to play with Little Billy and his friends. I’m trying to write these entries here to convey the undesirable user experience, and not whether I personally know enough to work around it. The average Fedora/Linux user doesn’t have 14 years of experience at dealing with this kind of thing.

Time for some (decaf) coffee.

Jon.

So yesterday’s post apparently got a little interest – mostly positive, insomuch as it’s realized that there are a few issues. But wait! There’s more! Call in the next 10 minutes and we’ll super extra double size your order!

Tonight, I decided to install a virtual machine containing a copy of the latest experimental Ubuntu (that’s known as “Ubuntu unstable”). To do this, I decided to install Hardy Heron via a CD image (bootstrap via ISO) and then perform an upgrade to the experimental release (dist-upgrade using apt). I downloaded a CD image from the MIT Media Lab using Firefox, then fed this into virt-manager. It failed, with a nice backtrace.

Now, this would seem to be the kind of activity that many people would want to undertake. Downloading images, booting them inside a virtual machine manager, and then using the resultant virtual machine image. But more than just that, what I wanted to do wasn’t exactly rocket science – skip the virtualization bit if that makes you think this is complex, I’m just talking about downloading a CD image and using it somehow.

The reason this activity failed was because of the SELinux configuration. The CD image Firefox had downloaded was in a temporary file download context, living in my Download directory, whereas virt-manager is not allowed to read from this kind of file until you’ve blessed it with a magical incantation of chcon. So, in this case, the “Microsoft Windows Vista” approach to security won out – get in the way so much that the user is quickly driven to distraction and inclined to turn it off. As I am, almost. After precisely one day of using SELinux in enforcing mode on a laptop (which has an encrypted disk and is only used by me) I’m about ready to throw it away…I’d hate to be an end user trying to manage this stuff.

No, this isn’t just like moving to UNIX permissions and groups. With the former, everything is well documented and widely understood already, but more importantly, there are nice tools to manage them. For example, right clicking on the file in the graphical file management application (nautilus) allows one to do many things, including viewing the SELinux context, but not actually changing this. I can’t find a nice pretty way for users to do this without having to grep through the policy files (to find out what the context should be) and then run other commands from the console. The point is, it’s a bit early in the game to have such complex policies with crazy numbers of contexts if users can’t easily manage this stuff. They need to be able to fix the problem too.

I tried to stop always blaming SELinux for everything by forcing myself to actually use it, but I’m beginning to regret this decision.

Jon.

So I just love SELinux these days. It’s so easy to use, clearly grandmothers everywhere should be using it to admin their systems.

I used to think SELinux was just a government inspired masturbatory exercise in protecting systems from themselves. Complex policies could be created (where, usually, only a minimal policy protecting actual likely attack vectors would suffice) and hours upon hours could be wasted figuring out the optimal number of possible context types to use on any given system.

Recently, I upgraded some machines to Fedora 9. And as part of that, I decided that I would, for once, run in enforcing mode by default. Rather than just be able to get on with whatever I wanted to do, I decided to protect myself from myself and my own actions. And this has already paid off. For example, tonight, I did the following:

*). Create a new filesystem.
*). Mount on /virt.
*). Just add KVM.

I ran virt-manager to create a new VM in /virt/Rawhide.img, which went ok until virt-manager repeatedly generated unpleasant backtraces. Why was it complaining that it couldn’t open the file it had just created? Then I noticed the AVC denials. My shiny new filesystem had no labels on it, which meant that files were being labelled with the default file_t, etc. A quick diversion into reading SELinux policy, brushing up on a half dozen tools, and it was obvious that all I was missing was the following:

sudo chcon -t virt_image_t /virt/Rawhide.img

All I had needed was a simple change of context to virt_image_t (because all virt images always obviously live in the same place, nobody could ever possibly want to do what I just did) and then a quick restart of virt-manager. I could also have helpfully followed the advice of the AVC tool, rebooted my system and instructed it to relabel. That’s not inconvenient advice at all, that’s just ease of use. Or so friends who’ve spent any time in Redmond, Washington might tell me.

Ok. Even I can’t take my own sarcasm any more in this post. So, let me just cut to the chase and say it. SELinux annoys me every bit as much as it did when I first tried it about a decade ago, and I refute the notion that Linux distributions should be inflicting complex policy upon unsuspecting users. SELinux should instead be used to protect specific system services that are likely to be used by remote attackers – web services, file servers, and the like.

To me, distributions should save complex policy for optional spins and products targeted at the “security paranoid types”. But I shall leave it turned on for now, because I want to understand just how “misguided” I’ve been all these years turning it off the very first chance I get.

Jon.