Hacker News Reader

Comment by vidarh | Hacker News Reader

The reason for this is that SELinux is a nightmare to configure, and lots of peoples expectations break when dealing with it and they usually don't know how to fix things without just disabling SELinux entirely. For Android peoples expectation has from the beginning been set to expect to run into security restrictions.

View on HN

This is what people were saying not too long ago on Windows when we'd complain that the apps didn't work if the user running them wasn't a local admin. Now you'd be hard pressed to find non-legacy software that doesn't work as a non-admin. In the commercial world, pressure can be brought down from on high - executives and IT purchasers discriminating against shitty software. What about FOSS? If the community has a 'meh' attitude with SELinux then things won't be easily SELinux compatible because devs don't give a shit. The same way most devs don't give a shit about most security related topics.

I'm really worried that Linux has become a liability. The lax security practices of the culture its part of are obvious. What now? Do we migrate to OpenBSD? I've been considering this at work. It just seems that the culture surrounding OpenBSD just takes security more seriously.

The idea that we can just put a application on the internet sounds dangerous to me. If its isn't hardened by something like apparmor/selinux and also behind some kind of application-level firewall (or at least snort), then we're just asking for trouble. Something has to change. The status quo is now failing us. How many high-priority patches have there been in the FOSS world this year?

Sadly, I worry more about my linux machines than my windows machines.

That's much, much less true than it used to be. These days there's great tools for managing and modifying selinux policy, and much better reporting of what was denied, when and why, and how to fix it.

The "Selinux is too hard for mortals" thing is a relic from the early days of its inclusion into linux, and turning around this attitude is important.

Depends how well integrated it is into the system. I tried to add any MAC to my Arch and discovered that: 1. doing everything from scratch for Tomoyo, including plugging it into grub config and creating your own policies is easier than even getting proper tools for selinux 2. Tomoyo behaves like Apparmor (policies on names not inodes), but can do more (ioctls, devices, more granular network controls) 3. Nobody uses Tomoyo and I really don't get why...

Yeah, it's going to be an uphill struggle on any distro that it isn't already well integrated into - there's a lot of effort that goes into making SELinux in fedora/RHEL/etc JustWork(tm). Duplicating this on a distro without tight SELinux integration is going to be hard - but I tend to feel that if you use arch, linux from scratch or other similar distro, it's not really fair to blame SELinux ;)

I disagree. The tools are awful and terribly slow to execute at best. Then you occasionally get shafted with a relabel.

Can you be more specific? There's lots of different tools available - there might be some better options available than what you're using. And while tools that change things (e.g. setting booleans, changing context rules, etc) are unlikely to be instant in the near future, as the policy needs to be re-compiled, this has been improved, particularly for booleans. You can also batch updates together, which is a much nicer experience if you're trying to set a bunch of things at once. e.g. semanage -i <( echo -e "boolean -m --on httpd_use_nfs\n boolean -m --on httpd_use_sasl") That said, "this admin command I rarely use takes 30s to run" (30s seems to be about the average on RHEL 6/7) is to me an odd reason to try to avoid an important security feature.

I don't recall the last time I had to do a full relabel on a production system. Not saying it hasn't happened, but I can't recall an instance.

Overall, I spend less time managing SELinux (and that includes the custom policies I maintain) than I do managing IPTables. It's really not the nightmare it's made out to be.

It's not that it's too hard for mortals, but that it provides a level of resistance people are not used to, and don't know how to deal with, and where the easiest solution is to turn it off.

Whereas on Android, people expect the barrier, and developers don't expect to be able to disable it.

Reply on news.ycombinator.com