271–280 of 461 posts
I like apparmor better. Set it up for high attack surface apps like browsers and vms.
I can't say my apparmor experiences have been great. SELinux and Apparmor are just two heads of the same problematic coin. As other comments on here point out, it's easier to have one sane policy for docker and containerize everything else.
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…
Pour one out for the Machine God.
My last experience with SElinux (around 10 years ago) I got this exact same issue with the login manager while trying out Fedora... and after fiddling around and working around it, another issue, and another - it must be turned off, it's clearly not suitable for general purpose usage and shouldn't be enabled by default (and isn't on most distros).
I like apparmor better. Set it up for high attack surface apps like browsers and vms.
I can't say my apparmor experiences have been great. SELinux and Apparmor are just two heads of the same problematic coin. As other comments on here point out, it's easier to have one sane policy for docker and containerize everything else.
Also, you are not supposed to ise containers as a security boundary??
Earlier quoted context omitted.
Not sure about need but I do remember it being a pain in the ass to run anything that expects to be managing docker inside docker. Things like self hosted gitlab ci where its trying to start up containers itself.
Mounting the docker socket into a container works. If it's advisable is another question, as that gives full control over all other containers (and likely more)
At that point you may want to just run it on the host, but basically you'd better trust whatever it is.
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 always felt containers were always about packaging and deployment, not security. Any "security" was a byproduct of isolation, not an end goal.
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…
There is truth to this, and it nails the fundamental asymmetry of the bad guys vs good guys in the security war. To program selinux you need to understand the software you run at the syscall level. and potentially have a deep understanding of its file usage, particularly if it’s doing ipc.
In general, I think that is a good goal. More understanding is more understanding and that is Good. In practice? I equate it to the problem of writing secure and robust code in C, I don’t know how good you have to be todo it and I basically assume that anyone who says they do is full of shit. I have contributed to the Linux kernel, I have decades of UNIX and specifically Linux experience as a software engineer, and I am still surprised when I fire up strace from time to time. You look at something like the recent Dirty Pipe bug, and I have a difficult time accepting that many people can fully grasp it all. The cost of a fairly simple system interface is all the subtlety and edge cases.
Selinux is a beast but there are tools to help with determining which settings need to be applied.
If you desire a truly locked down system, where you have a person or can afford a person dedicated to its security it's a good tool. Otherwise just turn it off.
How likely is it your server is going to be actively attacked? Usually very unlikely. We don't count the random and always present background brute force attempts, they're just background noise.
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…
There are many many problems.
One of the biggest problem with SELinux is that it is trying to graft Mandatory Access Controls on a userland that is not designed for it.
Unix, frankly, is not designed for security. It is designed to get work done by writing a bunch of little buggy C programs that you string together in novel ways.
Security is something that was grafted on it. And it shows.
How many decades of security vulnerabilities have occurred because of a shared /tmp space? 40 years?
How do you graft access controls on a system designed with no access controls and potentially billions of combinations of programs, paths, and various other resources without breaking anything?
The answer is: You don't. You can't.
Were as you have a system designed for security, like Android, and literally hundreds of millions of fully SELinux-enabled fully locked down user-facing Linux devices are out there being used by people who haven't the faintest clue what "audit2allow" is and wouldn't understand it if you tried to explain it to them.
So it's less of an issue of "we all use software that we don't understand". SELinux is complicated enough that you can devote your life to trying to understand it and still fail to craft good rules for other people.
It's more of an issue of "Linux userland follows the basic Unix design from the 1970s which is kinda shit if your goal is security".
It is just bad design. Pure and simple. That is all there really is.
However there is a way out.
The way out is to give each process and each user their own little itty bitty special Unix environment where they can do whatever they want. And then you use strong divisions to keep them mostly unaware of each other. Use a default deny policy and only poke holes in it when required.