Hacker News Reader

Comment by sergioocon | Hacker News Reader

I've been using SELinux in my Fedora the last 3 years, always on enforcing mode.

No major problems, just minor policy changes needed that the helper was already suggesting and that were easily fixed.

With the only exception that SELinux does not like my iPhone.

I just fixed a bizarre problem on Fedora by disabling SE. By the way, the user is using a PC I configured with used hardware, partly from me. It's supposed to be a just-works system, meaning that it runs Fedora and I did no special configuration at all.

That was the error description I got: "When starting the network does not work. I have to do a lot of things to make it work." Later I got more infos: "It says there are 7 errors. If I let it fix it it has to restart and then works".

It turns out that these 7 errors are all SE-Linux-Errors. Something about /etc/resolv.conf not being readable. The error helper suggests to fix it for now and also some command to fix it permanently, those commands fail and do nothing. So of course I just deactivated that SE-bullshit.

Really, fucking vanilla Fedora on a mainstream Gnome3 desktop. What the hell are they thinking?

I've used Fedora on the desktop for about five years and never had this issue. Maybe they were thinking you shouldn't change permissions on files in /etc unless you know what you're doing?

I did not change any permissions. Like I said, no modification from my side. Vanilla Fedora.

If you'd post the actual errors, I'm sure we could help you with that.

You mean the actual error message? Sorry, it's already solved now and I didn't write it down. It was in Spanish, so I also don't remember how it was worded. But its content is correctly described above: Unable to open /etc/resolv.conf.

And btw, that is exactly what I don't want. I do report errors, I solve bugs. But I don't want to debug SE-errors, which just because of its paranoia makes perfectly normal usage impossible, so far that distros that enable SEL spit out errormessages immediately after installation.

I don't see its purpose anyway.

The main value in SELinux is to protect apps against things they should never be allowed to do (like your web app reading /etc/shadow or notepad listening for network connections) so that even if they get hit with a 0day, they're still not really vulnerable because the SEL stuff blocks all the bad things they could do. It really truly works in practice to prevent a bunch of bad stuff. In reality though, most people just disable it because it's a pain to learn and deal with.

I know. But thanks for the answer. It is not what I meant, but it responds to what I wrote.

A security-solution that makes normal use impossible is not a solution. Security solutions never work if they make usability worse. SELinux goes farther, it also makes functionality worse till impossible. That is what I meant when I wrote that I don't see the point of it.

Something like that can be a good solution if you are manually hardening a specific process. As a general security solution it is completely unfit. I don't see the point of pushing it for that. Fedora should never have activated it.

> I've been using SELinux in my Fedora the last 3 years, always on enforcing mode. No major problems

I think the only problem I've encountered has been when Virtual Box (or was it VMWare?) tried to compile and install its custom kernel-modules, while using UEFI with secure-boot. They wouldn't load, because they weren't signed. Took me some debugging to figure out what was going on, but it was easily bypassed.

The solution was to disable secure-boot and just boot UEFI in "regular" mode. Felt a bit like fixing things by running as root/admin, but apart from that one story, I've had absolutely zero other issues with SELinux. Fedora has implemented it really well.

Microsoft's Secure Boot in the UEFI isn't SELinux[0]. It's actually not difficult to get VBox/VMWare to play nice with secure boot[1], once you've generated your custom signing keys. I keep a .sh on my machine to sign the latest kernel after each `dnf update`. Weirdly, my laptop had trouble booting with Secure Boot disabled so I was forced to figure out how to get them to play nice.

[0] https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Sec...

[1] http://gorka.eguileor.com/vbox-vmware-in-secureboot-linux/

> Microsoft's Secure Boot in the UEFI isn't SELinux

You may be absolutely right here and I may have incorrectly conflated the issues.

That said it's UEFI secure boot, not Microsoft secure boot.

Microsoft helped create the spec, but anyone is free to implement it and use it without any Microsoft involvement.

Maybe you're conflating some things too ;)

Reply on news.ycombinator.com