Live data from Hacker News

SELinux is unmanageable; just turn it off if it gets in your way

ctrl.blog

181–190 of 461 posts

Re: SELinux is unmanageable; just turn it off if it gets in your way

#181
I agree that SELinux is largely unusable in the real-world (especially for custom apps). I've had better experience with path based MACs like tomoyo and apparmor. Firejail is also great for end users who want to safely do online banking and surf the web at random on the same machine.

IMPO, this sort of isolation is the future of endpoint security. Linux has seccomp (to filter syscalls), landlock (to limit filesystem access), and other ways that devs can build these restrictions into their source code (no external MAC needed). I've lost count of the major and minor MACs that Linux offers now. OpenBSD has pledge and unveil that basically allow the same sort of thing.

I would not consider docker/podman as equivalent. They are great for bundling and running apps, but they are not doing mandatory access control. So be careful if you consider docker as a replacement for SELinux... it's not the same thing at all.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#182
post #134

The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…

I would argue that the fundamental problem is that the companies selling software "engineering" products do not actually take any responsibility that the product they have engineered works as intended. (see: https://www.snopes.com/fact-check/car-balk/ )

And of course, the main reason they do not take the responsibility is that the customers won't pay for it.

It is kind of interesting. We are very good at making bridges that do not fail unexpectedly, even if there is unlimited amount of unknown failure modes when working with physical materials. And on the software side, well, managing to come up with a fizzbuzz without failure modes is used to screen people on interviews. What would be similar for bridge engineers? Here is a hammer, nail and two pieces of wood. Can you make the two pieces of wood stick together?

Re: SELinux is unmanageable; just turn it off if it gets in your way

#184
post #134

The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…

Let's say you want to build a good, secure application. How do you know what files your application will try to open? What syscalls it wants to call? This almost looks like a hint to OpenBSD's pledge and unveil system calls. I'm just a hobbyist, but regarding we all run software we don't understand what I like (again) in OpenBSD is that I feel I can largely understand/control what's happening in my system, it quite f…

You can use strace to get this information. Linux also offers seccomp and landlock which are very similar to pledge and unveil.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#185
Basically linux is moving from a hobbyist operating system that a single person can reasonably manage in their spare time to an enterprise ish complex monstruosity that requires training and a time investment. Probably because the main Linux sponsors have found that it's the only way to make money with it.

SELinux... systemd... who knows what's coming next.

Let's not forget ipv6, although that's not a linux specific problem.

Edit: went through the discussions and it appears that all defenders of SELinux have used it in a paid professional context where it's justified to have a tight security polities. Hobbyists can't afford that time investment.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#186

Eh, I generally disagree - but not completely. Set SELinux to permissive for your personal systems at your own relative risk. Never disable it, you'll end up in a situation where nothing is labeled and relevant policy adjustments probably don't exist. Making re-enabling it later a nightmare. I'd argue it's particularly advantageous for desktops where untrusted software is a more common occurrence... and other control…

> I won't say it's easy, an employer of mine paid for two weeks of training that focused a lot specifically on this.

... and that's the problem. If something requires two weeks of training it's not hobbyist / small business friendly.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#187
post #2

As an experienced RHEL admin, a few years ago I probably would have said this is very bad advice in any professional context, and you should spend the time to learn it because it will save you one day. Now, I think my advice would be: Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way (ie no root containers, be very careful with volume mounts, etc). Yes, they aren’t as matur…

AppArmor is great. It can do much of what SELinux does, but it uses plain configuration files as opposed to incredibly obscure and clunky filesystem-level hacks.

AppArmour assumes everything is allowed unless it is explicitly denied by policy, SELinux assumes everything is banned unless it is allowed by policy. This makes SELinux fundamentally more secure because unlike apparmour you cant forget to deny some access that leaves you wide open, instead you forget to allow things and your app breaks. It also makes SELinux more complicated to implement because you have to allow everything you need or your app breaks whereas apparmour lets you deny the things you're worried about and ignore everything else.

SELinux also supports interesting things like applying security levels and contexts to data, so you can have data that is only accessible to appropriatly cleared users in one department but not to people with similar clearances in other departments. Very few people use this stuff though.

Selinux uses extended attributes to store its labels which is a pretty standard way of associating metadata with objects, and is supported by most standard unix commands (via the -Z flag) so I'm not sure what you mean by "filesystem hacks". Fundamentally they are both implemented as security modules in the kernel and do pretty much the same thing, which is best depends on whether the added security of SELinux is worth it to you.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#188

This is bad advice. SELinux might be hard, but it's neither unmanageable, nor it gets in your way when configured correctly. I've deployed both AppArmor and SELinux in high security environments, and they're nice layers of security to have. Yes, it has a learning curve, but it's worth it.

> I've deployed both AppArmor and SELinux in high security environments, and they're nice layers of security to have.

> Yes, it has a learning curve, but it's worth it.

Let me guess... you were paid full time to do it...

Re: SELinux is unmanageable; just turn it off if it gets in your way

#189
post #61

Earlier quoted context omitted.

Container approach is not always feasible, for example when you need to stay on bare metal. There are Linux applications where selinux definitely gets in your way and there are legitimate reasons to turn it off completely. edit: I like how I'm getting down-voted for sharing factual information. No-one in high frequency trading employs containers because it doesn't help soft-realtime, low-latency goals. There are othe…

> when you need to stay on bare metal What cases can linux containers not handle? Containers can access GPUs, /dev/kvm, block devices... I'm having trouble thinking of anything they can't do. After all, they're just processes in a glorified chroot, not that different from processes on the linux host.

I've had quite some problems setting up DPDK and other device drivers inside of containers. It looks like it should be easy, yes, but then reality hits you in the face.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#190

This is bad advice. SELinux might be hard, but it's neither unmanageable, nor it gets in your way when configured correctly. I've deployed both AppArmor and SELinux in high security environments, and they're nice layers of security to have. Yes, it has a learning curve, but it's worth it.

> I've deployed both AppArmor and SELinux in high security environments, and they're nice layers of security to have. > Yes, it has a learning curve, but it's worth it. Let me guess... you were paid full time to do it...

> Let me guess... you were paid full time to do it...

It was my job, but was a one time requirement. I decided that it was the right way, learnt and made it work.

And it solved the problem, rather elegantly.

I'm driven by my curiosity and desire the do things the right way.

Post reply on HN