Lazy ass humans. Externality - not the victim of your own decisions.
SELinux is unmanageable; just turn it off if it gets in your way
161–170 of 461 posts
Re: SELinux is unmanageable; just turn it off if it gets in your way
#162Earlier quoted context omitted.
> Yes, it has a learning curve, but it's worth it. That depends wholly on the circumstances in which those tradeoffs must be considered - additional security vs ease of use. For people who don't work in banks and whatnot, the choice is probably rather simple to make, they'll just prefer to do whatever will let their code and software run as they want (be it permissive mode or disabling it). In those circumstances, SE…
> That depends wholly on the circumstances in which those tradeoffs must be considered - additional security vs ease of use. Of course, horses for courses. That's always implied, and I always keep that in mind. However, if there's a case which needs that level of security, telling "Nah, just disable it, we'll do containers instead" is wrong at best, very dangerous at worst. Also, I find having a background knowledge…
> However, if there's a case which needs that level of security, telling "Nah, just disable it, we'll do containers instead" is wrong at best, very dangerous at worst.
Agreed, though partially. Those two technologies don't have to be mutually exclusive, though they sometimes are considered to be (e.g. working around the "system limitations" by using containers, when both could work in unison).
There are cases where you'll want containers AND SELinux/AppArmor. There are cases where you'll want full blown VMs. And even in regards to containers, there are multiple classes of technologies to consider: LXC/LXD, jails (BSD), containerd/Podman, Firecracker/gVisor and so on. And also approaches, like rootless containers, user remapping etc.
My point largely is that people will try to "get things done", everything that impedes them from doing that be damned (in their eyes)!
Re: SELinux is unmanageable; just turn it off if it gets in your way
#163the linux fiefdoms have a serious UX problem. SELinux being a prime example. As the article articulates, no wonder why people just turn it off. If your subsystems are not consistent, discoverable, palpable, and most important logical your setting yourself up for lousy adoption. And just "reading the docs" does not solve this problem. Your subsystem does not get to consume my professional time slice. The reason docker…
Right, right, and right.
Even after mastering all the fundamentals of SELinux, six month later a different audit-related problem surfaced and “what was that command again?”
This link often saves me:
https://access.redhat.com/documentation/en-us/red_hat_enterp...
In fact, I condensed it to the following steps (outlined elsewhere in this OP by patrck, new HN user):
couple sysadm red flags:
1) The article author is Testing in PROD
2) selinux debugging relies on auditd, so sanity checks required.
df -P /var/log/audit # has space?
tail -1 /var/log/audit/audit.log # is recent?
semodule -DB # disable dontaudit
setenforce 0
# run the failing test
audit2allow -l
mk_semod() {
module_name=$1; shift
audit2allow -l -m ${module_name} -a > ${module_name}.te
$EDITOR ${module_name}.te || return
checkmodule -M -m -o ${module_name}.mod ${module_name}.te
semodule_package -o ${module_name}.pp -m ${module_name}.mod
semodule -i ${module_name}.pp
}Re: SELinux is unmanageable; just turn it off if it gets in your way
#164Earlier quoted context omitted.
This seems like something that WebAssembly (misnomer) is set to resolve, to some degree. Sandboxing capabilities is easy because all of the wasm module imports must be provided by the process that initializes the module, so you can view imports as a kind of list of "requests for capabilities".
I think that's leaning even more into the parents point. We make a sandbox (in this case a very inefficient one) -- we assume the sandbox is the only way to deploy software, but mostly it's not because there will be times you need more than the sandbox or the software doesn't work, and then you're running "privileged" WASM routines. The sandbox itself might even require some kind of leaky behaviour, such as accessing…
WASM will probably be always slower than native but call it very inefficient is unjustified imho considering the compiler needs to be fast enough to run in browser from what I have seen its around ~1.5x slower than native code with there still being many low hanging fruits to be optimized.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#165Longtime SA, constantly ribbed or outright insulted for my absolute hatred of SELinux. Yes, I just turn it off first thing. Well, used to when stuck with RHEL environments. If you want people to adopt and really use something at large, you need to make it simple, explain when and why it's useful, and document it well. SELinux doesn't do any of that particularly well. And now that most things are effectively running o…
Security can't be made simple. At the core what SELinux does is simply enforcing a policy. A list of "Should X do Y to Z?".
This is something that can't be implemented with just file permissions. What SELinux does is sandboxing every process it controls.
For instance, my cupsd is running as root. It's accepting connections on port 631.
If it started accepting connections on port 22, that's probably a bad thing. If it started messing around with /etc/passwd and /etc/shadow, that's probably not good either. It probably also has no business with my GPG keys, or /dev/sda.
But under the Unix permission model, if it runs as root, there's nothing you can do about it. It's root, it gets the entire system. If it has a hole, that's that.
SELinux first applies labels to stuff, then defines what actions can be done on what. So under SELinux there's a rule that says "A process with the label "cupsd_t can listen on a port labeled ipp_port_t". That's what lets it listen there, and absent a rule that allows it to listen on the ssh port, it's denied even if running as root.
So with a well implemented policy, if somebody exploits your cupsd, they can waste your paper. But despite it running as root they can't run a shell, can't open ports, can't mess with your password database, and can't install its own kernel driver. With the right rules, the attacker can find themselves at a dead end, where there's nothing useful they can do.
You can to some extent do this kind of thing with containers, but it really amounts to doing the same kind of work in the end to a large extent. If your container's security is at all useful you'll have to tell the system what should the cupsd container be able to do, in a very precise manner, and not just "eh, it can have root access to everything". At that point you've got another SELinux-like system to deal with.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#166The 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.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#167My advice is to ALWAYS turn it off. As soon as you install a new system, turn it off (together with systemd).
>As soon as you install a new system, turn it off good advice > together with systemd lol why
Because we didn’t ask for systemd. We like init scripts that we actually understand.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#168This article is a prime example of why one should think about the content of a page before accepting it's premise. I would argue that no solution in and of itself is complete. I hope someday we can get away from the idea that containerization is the complete solution. I have been a system admin for over 20 years, and it seems we still have not been able to get the concepts of defense in depth, and specifically many l…
SELinux policy can (and does, by default, on rhel-like systems) enforce the security guarantees the container frameworks provide.
This is very much an optimal scenario for SELinux when you have some macro-level policy restriction and you want to enforce it.
SELinux is just not very well matched for the usual scenario of trying to graft a security policy on software and a system admin that is completely unaware of it.
This means people get frustrated when an Apache server can’t read some files in some folder arbitrarily set in the config, because there never was any policy of the Apache server only being able to read files with the right security context, that was never part of the HTTPD sever documentation, it’s a default system policy called selinux-policy-targeted that originates with Fedora.
Now if you run the same HTTP server in a container, you have first class concept of a volume, and the container framework is aware of that and can label files with the right context as needed; in fact with Podman it will even use MLS to prevent cross-container contamination.
So IMO containers are not in any way incompatible with SELinux, they are in fact a great abstraction match and they work great together. There’s been many container escapes that were prevented by SELinux policy.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#169As 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…
As a completely new admin, could you elaborate on "be very careful with volume mounts"?
In the k8s env I run, the filesystem is backed by ceph, which creates persistent volumes that the different pods can claim. Is it just "be careful not to mount docker.sock"?