SELinux fails again (Fedora 20 edition)

January 15, 2014

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.)


Comments on this page:

By Elijah Buck at 2014-01-15 16:59:51:

It looks like 'semanage export' should print out any local policy customization. Then you can wipe out the customization, with, for example 'semanage boolean -D'.

Try a full relabel?

 # touch /.autorelabel
 # reboot 

Can the vpn server require ipsec by policy so that l2tp alone doesn't work?

This is where some clever person blames in addition to NetworkManager for being willing to continue setting up a L2TP VPN without IPSec.

s/instead/in addition to SELinux/

FTFY. :-)

SELinux isn’t the only conceivable obstruction that might cause NM to fail to set up encryption. Silently falling back to an unencrypted connection is equally undesirable in any such case.

From 46.144.78.131 at 2014-01-16 05:00:46:

nice quote from fedora's wiki (http://fedoraproject.org/wiki/Upgrading):

"Upgrading directly using Yum

Upgrading directly from one release to the next using yum is not explicitly tested by Fedora QA and issues with it are not considered blockers for a release"

This is one of the 'it works for me' moments. Personally, I do not waste any time on upgrades, I just reinstall keeping my data on a separate partition. No problems at all since I started doing this, it takes all of 15 minutes per year to get my laptop to a new fedora version.

Hey Chris, I totally feel your pain. You might find "Dan Walsh blog" mighty helpful.

And possibly this specific article: http://danwalsh.livejournal.com/64142.html

By cks at 2014-01-16 12:00:08:

@Elijah Buck: semanage export doesn't seem to show anything much. A full relabel didn't improve the situation, and in fact even going in with manual use of audit2allow based on looking at /var/log/audit/audit.log didn't make things work, although there were no SELinux denies logged there. At this point it mystifies me.

@Al Biheiri: Dan Walsh's advice is undoubtedly very good for people who want to make SELinux work. But as mentioned, I don't care about SELinux, I just care about making my machine work. Creating local policies is the remedy that the SELinux alert tool suggests and so that is what I do (and it doesn't seem to have worked here).

Written on 15 January 2014.
« Real support periods versus nominal official ones
Debian does not have long term support »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 15 15:54:45 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.