Wandering Thoughts archives

I'm considering building a custom laptop environment

Back in this entry I talked about how my work laptop was still running Fedora 14 and going to stick there, and that what was important about my Fedora 14 Gnome 2 environment was sshmenu plus my customizations for the Gnome 'Command Line' applet. This is all well and good and my logic is still impeccable, but the whole Fedora 14 situation is becoming less and less tenable. It's not just the lack of security updates or even updates for Firefox and Chrome updates; it's also the lack of modern software, including modern support for, say, wireless networks using WPA2 Enterprise authentication (guess what we have one of on campus).

The bad news is that I see no signs that any standard desktop environment will ever have what I want. The good news is that I already have an even better replacement for the command line applet and I can either use sshmenu straight or bash together some sort of alternate. All I would need to do is put together a custom window manager environment that had all of the necessary functionality. This is not trivial but I already have some experience with it.

I don't think that my usual window manager would really work on a laptop; it relies on a lot of chorded mouse actions that are easy with a separate mouse but would probably be very awkward with a trackpad. The broad strokes of the Gnome 2 environment are perfectly fine, which basically means an area for necessary applets and then some buttons to launch programs (and scripts) that I care about. I would need to find an applet container program, assuming that the window manager I pick doesn't already come with one. As far as I know, things like NetworkManager (pretty much essential for a laptop in my view), power management, and so on are still available in applet or standalone form (and so I will not have to write anything to, for example, suspend the system when the laptop lid is closed).

(While it's tempting to reuse fvwm and just write a different configuration I'm not certain that it's the right approach. On the other hand the simple window managers that everyone talks about tend to be tiling window managers and I don't think that would work on a small laptop screen.)

This would be a certain amount of up-front work. On the other hand I'd get to update to current Fedora and I'd also fix my laptop environment issues for good; I'd probably be fine no matter what the various Fedora desktops did in future releases. On the whole it's actually pretty tempting, especially when I tell myself I'm going to have to do this someday and it's just a question of when I do the work.

(I admit that it bugs me to have the laptop stuck on such an old Fedora release. Getting to something modern is a pretty attractive idea all by itself.)

What the SELinux community should be doing

Beyond a new errno value for SELinux I don't have any specific technical suggestions for things to do to SELinux to make it work better. Instead I think that the real next steps are social ones (because the most pressing issue is a social one). As it stands the SELinux community is simply not ready to start fixing any technical problems because they clearly do not understand the real problems.

The community's first job should be to understand the real problems that exist, both with SELinux and in general, and to think deeply about how and whether SELinux can solve them (and if there are some problems that SELinux cannot solve and should gracefully bow out from). One vitally important thing here is to actually shut up and listen to the significant number of sysadmins who have problems with SELinux (I say 'shut up' because the last thing the SELinux community needs right now is yet another round of their toxic mistake).

Put another way, SELinux needs to solve real problems and by 'real problems' I mean problems that are actually affecting people in the real world (not theoretical possibilities of threat models). If it cannot solve real problems for people it needs to at least not get in the way. The current situation that many sysadmins are experiencing is that SELinux does not solve real problems and it also gets in the way. The SELinux community needs to fix that (and the answer is not 'lecture sysadmins more' aka 'user education', that's the toxic answer). Step zero of fixing it is understanding how and why SELinux is not helping sysadmins and that requires actually listening to them when they tell you.

(Trust me, if you start genuinely listening people will give you an earful. The SELinux community will probably not like what it hears and think that some of it is wrong, but shut up and listen. It doesn't matter what reality is; what matters here is what sysadmins perceive and believe. Only once you genuinely understand someone's perspective can you begin thinking carefully about how you might change it. You might also come to the uncomfortable conclusion that there is truth in their position.)

My personal view is that the SELinux community should also consider the idea that SELinux is only a good fit for certain sorts of machines. It may be that part of the solution is actually a recommendation that people should normally turn SELinux enforcement off on some sorts of systems.

SELinux should have its own errno value

Years ago I mentioned in passing that SELinux should have its own errno value. Today I feel like running down both the technical details of how I think it should work and why it makes sense.

First, I don't think this should be specific to just SELinux. The reality is that Unix kernels are increasingly growing security restrictions over and above standard Unix permissions, all of which suffer from the same visibility problems that SELinux has. Rather than give them all different errno values, I think that there should be a single errno value, call it ESECURITY, which means 'this action was denied due to some additional security policy'.

(It would thus trigger for things like Ubuntu's additional security hardening.)

The advantage of such an errno is that it tells everyone where to look, or at least that there is no point in looking at standard Unix permissions. You know right away that something odd is going on and won't wind up spending a bunch of time looking at file permissions, UIDs, and so on and going 'this should work, why on earth is it failing?'. Today the last is quite common with SELinux (and other such things) and is one large reason they are so frustrating for many people.

The Unix tradition (in general) is to add new errno values for new forms of system call failure; this is the tradition that gave us, for example, ESTALE. 'This operation was denied because of an additional security policy' is clearly a new form of system call failure and so it makes complete sense for it to have a new errno value (and more than one if it becomes necessary). Returning EPERM is not good enough because in reality almost everyone today who sees EPERM assumes that the cause is normal Unix permissions (as shown by all the stories of people who did not think to look at SELinux until much, much later).

(Some people will argue that adding a new errno return is not standards compliant. Fortunately for us, Linux has never promised to be fully POSIX compliant; Linus himself has said in the past that Linux sticks to POSIX only when POSIX makes sense. Refusing to add new errno values for new forms of failure is neither sensible nor useful.)

Why building RPMs for a different architecture is a hard problem

I was recently grumbling about how difficult it is to build 32-bit x86 RPMs on a 64-bit x86 Fedora system. The short version is that despite the presence of various things to help cross-building, like setarch and rpmbuild --target=..., the only way I've found to cross-build binary RPMs is to use mock to create an entire minimal 32-bit Fedora install in a buildroot and then use that minimal install to recompile your RPM. At one level this sounds absurd: I'm shuffling around hundreds of megabytes of packages and disk space to create the 32-bit Fedora buildroot when my 64-bit install is already fully capable (at least in theory) of building 32-bit programs. But once I started thinking about it, I realized that cross-building RPMs is actually a really hard problem that is basically impossible to get right. The problem is that cross-compiling things in general is very fragile.

My system doesn't have a duplicate set of 32-bit programs; all of its normal programs are 64-bit ones. To cross-compile and cross-build properly, every program that might write architecture-dependent data needs to detect that it is running in a cross-building environment and then write 32-bit data instead of native 64-bit data. This is not just the C and C++ compilers, it may also include things like Python writing bytecode files and the like. In fact, in some situations it's impossible to make this work without a 32-bit version of a system program (or huge local hacks to the program). As a result it's very easy for something to quietly go wrong with a cross-build process such that a 64-bit something sneaks into what is theoretically a 32-bit RPM. Various sorts of explosions are going to ensue when this binary RPM is actually installed.

(Nor can RPM reliably detect this, since it doesn't necessarily know what's 64-bit dependent in a package's files. At best the RPM build process could catch obvious cases it knows about.)

One way to put this is that cross-building requires all of the 64-bit programs involved in building the package to faithfully emulate their 32-bit selves. This is both non-trivial and not something that many projects are even interested in. Setting up an entire environment with the 32-bit versions of everything actually is the simpler answer in the general case. The 32-bit versions are basically guaranteed to do the right thing since they're not emulating anything, they're just being their natural selves.

(This is in part the kind of thing I write down to get it all straight in my head. I'm sure it's nothing new to people who worry about cross-compiling and cross-building packages, and this particular case gets off easy since you can at least still run 32-bit x86 programs on a 64-bit x86 system, which is a lot more than you get in many other cross-compilation situations.)

Sidebar: the hard and the impossible situations

The hard situation is when the package being built interrogates a system program for some core configuration information or compilation option, like 'how big is a <X> data object'. To be a faithful 32-bit emulation the program has to lie, to say that ints are 32 bits when in fact they're really 64 bits. Many programs aren't going to do this (whether the data is generated on the fly at runtime or saved at build time and then just produced for anyone who asks).

The impossible situation is when the package being built compiles an extension for something that supports them (such as Perl or Python) and then tries to load the newly compiled extension into the system program during the build process. To cross build properly the compiled extension must be a 32-bit object, not a 64-bit one, but now you're trying to load a 32-bit extension into a 64-bit program.

(One of many ways that this can happen is a commendable desire on the package's part to make sure that its newly compiled extension module actually works. You test the extension module by, well, loading it and seeing if it works properly.)

Both of these work right if the 'system' program actually is the 32-bit version instead of the 64-bit version.

SELinux's toxic mistake

Okay, it's not SELinux's (the technology's) mistake. It's the mistake of people who support SELinux, what outsiders see as the SELinux community. From an outside perspective it's basically the same thing. The toxic mistake is this:

Seriously, stop disabling SELinux. Learn how to use it before you blindly shut it off.

(via, which is another illustration of this, from @jordansissel.)

Let me translate this: 'the beatings will continue until morale improves'.

When people say 'this security tool is too hard to use, gets in my way, and isn't giving me any real benefits', telling them 'it's great if you only spend more time learning how to deal with it' is doubling down on your problems. If you then compound things by telling people that they are just stupid and lazy, don't be surprised if they immediately tune you out because you're acting like a zealot (you may or may not be one, it doesn't matter to people).

It's been apparent for years that SELinux had serious problems in real life (regardless of what the theory says). For example, it's widely considered standard practice to disable SELinux immediately on server installs (as mentioned in the Twitter thread I got this from). The reason people reject SELinux in its current state is pretty simple: security is not their top priority. Unless you are a high risk target, spending almost any time beating SELinux into shape on your machine is a bad tradeoff and pretty much a waste (partly because SELinux is just a backup).

(If SELinux works when you don't touch anything you might as well leave it on, but turning it off the moment it costs you any time is a perfectly rational reaction. So is turning it off immediately so that it can't waste your time.)

In the face of this, for the SELinux community to feel that people are stupid, lazy, or ignorant for not jumping through the magic SELinux hoops and all would be well in the world if only they would mend their woeful ways is breathtakingly stupid and counterproductive. At a stroke it sabotages almost any chance SELinux might have to actually make meaningful improvements. Not that such improvements would be easy even if the SELinux community listened to what the world was telling them (because it's a hard problem), but if the community did listen they might at least have some sort of chance.

(Not that this sort of blindness is new in security or in general.)

(What I think the SELinux community should be doing is a sufficiently large issue that it doesn't fit in the margins of this entry. Of course it's an open question if SELinux can be saved or is worth saving in general given its origins; I think there's a real argument that SELinux's security model simply does not meet people's real security needs by design.)