3 ms·

This 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 its

This 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 layers of defense on each level to soak in. I see multiple people espousing the belief (in the comments on this article at least) that containerization has solved this issue and SELinux is no longer needed. I can think of a certain chaos goose (Ian Coldwater) who has been providing plenty of reasons why it's bad to trust containers alone for years. In my personal experience SELinux has stopped attacks in their tracks when a 0 day hit, until a patch from upstream became available and is an invaluable tool for blue team in general. It is not the most intuitive of tools, but most truly powerful tools are not intuitive, that seems to be a common trade off.

deno 4y ago
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.

deno 4y ago

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.