Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

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.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: