jcm’s blog

So without further ado, I give you Building Embedded Linux Systems - Second Edition, written by several talented authors, and also yours truly. I take overall responsibility for this edition, and I hope that you enjoy reading it.

The book is going to be hitting bookstores “really soon now”, just as soon as it’s done being printed. The update includes lots of changes to upstream kernel and embedded components that have happened since 2003, brand new material on the Real Time patchset and related technologies, as well as various other changes. It’s intended to be an overall insight into embedded Linux rather than a programmer’s guide - for that, you want to be reading the other O’Reilly books on the Linux kernel and Linux Device Drivers - but it will get you pointed in the right direction, even if you’re coming from a non-Linux background. If you know Linux, but don’t know much about embedded Linux and its unique constraints, you will enjoy this book.

Buy a copy, and make my day!

So I’ve been writing about a couple of weeks as a user of SELinux on Fedora. I thought I’d give an update about the experience.

After a week as a user of SELinux in enforcing mode, I had learned a few things. I had learned that it isn’t always possible (without using command line utilities) to download a CD image and use it to install a virtual machine, or to use an alternate location for virtual machine images, and a number of other (minor) issues. By this, I mean that none of these things can be done trivially by end users or developers who don’t know about commands like chcon, and their use. To many end users, this simply means these (seemingly quite straightforward) activities are now “impossible”, since they simply will not properly understand why they are not working in the way they had intended. In this case the appearance of us being secure has trumped over general functionality.

Late last week, I decided to allow my laptop to apply the latest Fedora updates. I rebooted into the updated environment (new kernel image) and tried to connect to my corporate VPN using VPNC. Although it was able to connect, the connection script generated repeated errors trying to run commands like “ip” and “ifconfig”. So, I spent roughly 6 hours on Sunday night reading SELinux documentation, books, whitepapers, commands, and the Fedora SELinux “targeted” policy itself. I concluded that the update had disallowed the VPNC domain access to the sysnetwork domain in which those various networking commands exist.

Without getting into specifics too much (BZ453236 has my analysis attached), NetworkManager is able to start VPNC because it runs in a system context (which has a specific policy item to allow access to network commands), whereas regularly started tty incantations of VPNC will run unconfined. In that case, audit2allow suggested adding:

role unconfined_t types ifconfig_t

Which was actually in a pending update to the policy (it hadn’t made the changelog so I hadn’t noticed it when skimming recent koji builds). I installed the new build, and lo-and-behold my VPNC worked again. I wasn’t particularly bothered by this experience - I learned a lot about SELinux policy, the different files, and how it all goes together that I’m sure has changed since I looked at this stuff nearly a decade ago. But I’m not blogging about this because of me, I’m thinking about the end-user experience. The user facing this problem might have filled a Bugzilla, and they might even have realized this was due to SELinux (no AVC denial messages given) and tried fixing the problem for themself. But they probably instead decided that something was broken with Fedora and just went away frustrated. Security trumped over functionality of a generic laptop system.

All I can do is hope that, in time, the community will realize the many uses that SELinux has, and the many that it does not. It’s great if you work for the NSA, have lots of servers to protect from the Interwebulous Tubes of the Internet, or are just a paranoid type. In those cases, SELinux has many advantages - especially if you’re running a timesharing system and distrust all of your users, to varying or equal amounts. This is one of many compelling justifications for SELinux to exist in Enterprise Linux products, and as an optional installation item on various other spins of Fedora - for example, for server targets. These are also good reasons to offer end users the option of turning on SELinux, if they desire.

But for the average Desktop user (you know, the type that we, as a community occasionally like to encourage…) SELinux often ostensibly gets in their way. You don’t have to choose to believe this if you don’t want to, but it can’t be managed graphically (that’s where most people will give up), the policy is highly complex (I’ve read bits of it), and what exactly does the average laptop user sitting behind a firewall with only a few non-external-facing Desktop applications need it for anyway? To protect them from themself? In case the guy in Starbucks is a l33t h4×0r? To protect them from a relatively minor subset of possible security attack vectors unlikely to be used against them at home? I’m still waiting to be convinced that it should *always* be on by default.

As a final note, remember that I’m not criticizing the Fedora community, SELinux developers, or other individuals. I’m saying that the end user experience is lacking in a few fixable ways. Mainly by bringing back an obvious option during installation that explains why Fedora offers this feature, and gives users who don’t want it a choice of turning it off.

Jon.

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.

I’ve created a “fedora” category and added an RSS2 feed to the fedora planet. This way, Fedora folks only have to wade through relevant postings. I should use categories and tagging more often.

Oh, and, “this is a test”

Jon.