Personally, I'll be keeping it disabled. I used to use selinux, but eventually stopped as I didn't find the constant headache of trying to figure out why something wasn't working was related to SE or not worth it.
If you want to do something weird like allowing nginx or apache to serve your home directories, it takes maybe 5 minutes to google the correct se context to set on the directory and apply it, otherwise any standard installation works out of the box.
There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn.
Unlike with most open source software for things like selinux that disable a host of stuff by default, documentation cannot be an after thought. And why invent weird vague terminology, what is a context?
Things are complex as it is and people need to get things done. To have to waste man hours that could be used more productively more than once only to figure out its caused by selinux 'silently' without any proper error messages or logging and you do the sensible thing and disable it.
setroubleshoot
> documentation cannot be an after thought
Take a look at selinux-policy-doc, it's extensive.
> what is a context
It's a type. But 'type' as it refers to files means something else. It's just a label that describes what kind of file it is. user_home_dir_t is user files, httpd_sys_content_t is content that can be served by apache, nfsd_fs_t are files that that can be exported by NFS.
> proper error messages or logging
Every single denial is logged and it contains all the details why it was denied. You're asking for SELinux to log why it wasn't allowed which is done by setroubleshoot but isn't possible in general.
Not quite true. Some need to have debug turned on. See my other comment.
Additionally, if you're running a desktop system and software installation is a frequent task, you'll have to deal with that constantly, often many times for the same application. At some point you're going to give up and say it's not worth it. Most people can't even stand the GUI based notifications of Outpost or ZoneAlarm in my experience.
Also, it's probably the best protection from a zero-day exploit there is.
I can see an argument for a defense in depth approach here, but if there's only one service per VM and that service is already restricted to only the stuff it needs to talk to on the network level I'm not convinced it makes much sense. As far as I know at least, SELinux won't be able to prevent kernel exploitation or the like.
If you already broke into the service and can make syscalls, well, there's really not much gain from that under my architecture at least - you can still only access what's already in that one service.
Then again, three were a plenty exploits against general FS or common calls like poll... Things you cannot limit in this way because they are used by apps in question.
But that's what selinux limits -- the "blast radius" from a compromised service.
If your Web server is on a private network with your app server and your load balancer, there's no way it can attack your database server. Basically, policies are implemented at the network and host level rather than the process and file level.
In contrast, network interfaces are well controlled. If people started with 'deny all' in their fw permissions then added the minimal necessary holes then lateral movement would be a lot harder.
I think the best argument for selinux/apparmor is that a lot of application specific security hardening can be packaged into standard configs. In contrast, there is little to orchestrate this for VMs/containers/physical hosts. Inter-VM/CNTR network control seems difficult (open vSwitch).
If we could have easily configured, hypervisor enforced firewalling and encrypted tunneling then that would be more useful confinement.
Sometimes is as simple as not having time for that. If I've urgent work to do, I can't stop my work and well my boss/client "hang on, I need to learn to configure SELinux first!".
The fact that it DOESN'T work out-of-the-box immediately and needs for me to configure it (regardless of how well documented it is) is its major pitfall. These things need to work without adding ANY burden to the user. Otherwise, they'll end up disabled.
audit2allow and audit2why are often helpful but at least as often they offer the wrong solution.
Did you know that some selinux violations are not even reported by default?
This was the case for me; selinux transitions are prevented by a filesystem mounted _nosuid_. The failure is not reported because transition failures are apparently so common and unimportant selinux does not report them by default.
Took me a looong time to troubleshoot this.
If it were actually that easy, then you wouldn't need this step since SELinux would just do it for you. Clearly that isn't the case.
Maybe it could be made more convenient by a tool that parses the log and automatically runs the commands when you answer the question with "y".
Right, it requires intervention by a person who doesn't actually understand the minutiae of what the software is trying to do, so obviously they can make a properly informed choice as to what is and is not a security violation. Modern operating systems are so broken...
Supposedly it should see the card arrive through hotplug and add it to the device list, but that has never happened.
I did have to kill pulseaudio 1st though..
might try that if you have not already
But also, worth remembering that this is a proposal for an experiment. One of the things they're going to judge is how much does it affect regular users.