2014-01-15
SELinux fails again (Fedora 20 edition)
I've always run SELinux on my laptop; it's how Fedora installs things, it's worked without problems, and despite all the bad things I've said about it I sort of consider SELinux to be the right thing to do so I wanted to keep with it. And unlike my other machines, my laptop is a completely stock setup at the system level and I don't do anything unusual on it. Then I upgraded to Fedora 20 with yum and things exploded.
(Some of the problems were fixed by 'restorecon -R /', which is not
unreasonable given that I upgraded with yum.)
The major thing SELinux did was it prevented NetworkManager from setting up IPSec for L2TP VPNs. This is a new failure in Fedora 20 (it used to work in Fedora 19). This is actually a very bad failure because for whatever reason NetworkManager was willing to keep on going and set up a L2TP 'VPN' connection without the IPSec encryption, giving me less a Virtual Private Network and more a Virtual Plaintext Network. So let me emphasize this:
SELinux significantly reduced my security in practice.
I would have been much better off without SELinux because then I would have had a VPN that was actually encrypted instead of one that I just thought was encrypted and that was instead allowing any random bystander to snoop my wireless traffic.
(This is where some clever person blames NetworkManager instead for being willing to continue setting up a L2TP VPN without IPSec. No. Wrong. The simple fact is that things worked securely without SELinux and they didn't work with SELinux. Ergo, SELinux is the party that broke things. Arguing that it is not SELinux's fault is not solving the actual security problem here. SELinux made my system less secure, regardless of exactly how that happened. If you argue that this doesn't matter you are not interested in security, you are interested in mathematics. Please stay away from my systems.)
Now let us talk about SELinux's bad user interface failures. In the
process of going back and forth with SELinux and my Fedora 20 upgrade, I
did a bunch of flailing around. I followed the directions of the SELinux
alert widget to add some new policies with audit2allow to try to fix
things in a relatively graceful way, I silenced some alerts when I was
running in permissive mode before I found restorecon and thought it
had solved all of my problems, and so on. What I would like to do now is
clear all of that away and revert to a stock Fedora 20 SELinux setup so
that I can dutifully report all of these policy problems.
I haven't been able to find out how to do so.
I am a relatively experienced sysadmin. I can read manpages, scan Python code, grep everything in sight, and so on. I have utterly failed to find out how to revert to a stock policy or to un-silence various alerts so I can use the nice alert program to report them as bugs. At this point it appears to be literally impossible for me to do this without installing Fedora 20 from scratch, and that's not going to happen.
(I'm relatively sure that it isn't literally impossible and that there is some magic incantation somewhere.)
As mentioned, I'm a sysadmin. If I can't figure out how to do this, what chance does a regular user have? In fact, what chance does a regular user have to make SELinux work in general when something like this happens? Even adding a policy exemption takes manual cut and paste work (and knowing what certain Unix documentation conventions are). Real security absolutely must be usable. SELinux is not and this is its largest failure.
The golden rule is what I said on Twitter: people use their computers to get things done. If your security system gets in the way of getting things done, people will remove it. If they can't figure out how to remove it, they will remove the entire system. If Linux is lucky, this will involve installing Ubuntu instead of Fedora. If Linux is not lucky, this results in another user saying 'well, Linux doesn't work, I guess it's time for Windows'.
(Have I filed bugs about this? Of course not. I can't. See above. To file bugs on anything apart from 'you have a massive UI fail here' I would have to install Fedora 20 from scratch, overwriting all of my customization and setup work.)
Real support periods versus nominal official ones
Suppose that you have a vendor with a support period of five years for their OS. This is great, since you can install a machine with that OS and get five years of support for it, right? Well, no, of course not. You only get five years of support if you install your machine right away when the OS comes out. If you install a machine two years after that, you only get three years of support for it; if you install a machine four years after the initial release, you get one year of support.
(We're assuming that the vendor doesn't extend the support period at some point due to popular demand.)
In a heterogenous environment where you're deciding on a project by project basis what software to use, you just have to consider support requirements when you're planning each project; each one can wind up using something different that fits its needs. Generally this is going to make any particular OS or software version less and less attractive for new projects as it gets closer and closer to its EOL, because more and more projects will have support requirements that run beyond the EOL.
(On the other hand you may see surprising usage even quite late, as new projects with short support requirements pick the old version for various other reasons, eg the people involved have a lot of familiarity with its quirks.)
If you want to run a mostly homogenous environment making a big use of this software, another important factor comes in: you now care a lot about how often the vendor releases new versions with new support periods. We can see this by taking the extreme case. Suppose that this OS vendor does releases only once every six years, leaving a one year period where you can't install or run a machine with support. You're unlikely to use this OS because you'd have to abandon it during that one year gap.
In a homogenous environment where you're strongly tied to a given bit of software on basically all of your machines, the worst case minimum support period you may actually get works out to be around the official support period minus how often the vendor does releases. If the vendor releases new versions every four years, the vague worst case is that you have to set up a new machine just before their new version comes out and so it gets about a year's support. The practical result is often that if the vendor only has what you consider a short overlap, you'll start dragging your heels on new machines as the time for a new version gets closer and closer; you really want to delay long enough to use the new version for its much longer support period.
(In practice you're unlikely to immediately start using the vendor's new version the day it gets released, so if you're unlucky you may have to install with the old version even for a while after the new one is released.)
This leaves sysadmins and other people really wanting a good healthy overlap of support periods after new versions are released. For a not entirely hypothetical example, five years of support coupled with a new version every two years gives us about three years of overlap for the worst case. That's a pretty respectable number that leaves me with little qualms about installing the 'old' version pretty much any time up to the point where we have the new version ready for production.
(There is also the related issue that real world support periods are shorter than they look.)