4 ms·

Running into edge issues and always trying to figure out if it was my container, Podman, or SELinux is making me very close to installing regular docker.

bongobingo1 4y ago
I want to love SELinux, sounds great, I can see the real value in it. Tried to deploy some containers on an SE system and it would block everything. Ok expected, it actually has great tools for discovering, suggesting and creating rules to poke holes where needed, but it only suggests those things post-facto. So basically you're left deploying a container and waiting for something to break, then inspecting SE logs and patching rules in (and folding all that back into your ansible or whatever). Maybe this is OK if its your application and you can dump it on a staging environment and push it through your 100% coverage end to end test suite to capture all requirements, but if its a third party - or maybe your test coverage isn't quite where you want it to be - you're basically walking out on the rope bridge blind. Not sure there is really a way to solve that. Perhaps it there was a `pledge`/`unveil` like system where all requirements can be discovered up front... Otherwise it felt like yours stuck running in SEDisable or SEPermissive for months collecting data (after every deploy). Maybe I just missed an obvious route to disable swaths of SELinux for rootless containers - where it probably doesn't have as much of an application. Sorry Dan Walsh :(
- yrro 4y ago
  > Maybe I just missed an obvious route to disable swaths of SELinux for rootless containers Yeah you can put container_t into permissive mode: # semanage permissive -a container_t AVC denials will still be logged but the operations won't be denied.
  - bongobingo1 4y ago
    It sounds like podman containers should automatically get that label so I'll give it another look, thanks!
    - yrro 4y ago
      Yeah, use ps -Z PID (from outside of a container) to check its label. Some other useful sources of info - the container_selinux man page tells you about container_t. And an index of Dan Walsh's blog posts about containers & SELinux can be found in the README of <https://github.com/containers/container-selinux https://github.com/containers/container-selinux>. And of course the RHEL documentation for creatign custom SELinux policies that inherit from container_t (for instance, I use it to allow processes within a container to read their certificates out of /etc/pki/tls which is normally forbidden. It's documented here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/using_selinux/creating-selinux-policies-for-containers_using-selinux#doc-wrapper https://access.redhat.com/documentation/en-us/red_hat_enterp...
- spinachsalad 4y ago
  > Maybe I just missed an obvious route to disable swaths of SELinux for rootless containers - where it probably doesn't have as much of an application. podman run --security-opt label=disable https://github.com/containers/podman/blob/main/troubleshooting.md#2-cant-use-volume-mount-get-permission-denied https://github.com/containers/podman/blob/main/troubleshooti... Note: Labeling can be disabled for all containers by setting label=false in the containers.conf(5) file. https://docs.podman.io/en/latest/markdown/podman-run.1.html#security-opt-option https://docs.podman.io/en/latest/markdown/podman-run.1.html#... But more secure way would be to add ":z" or ":Z" to volume and podman will auto-relabel source dir. Finally you can use nuclear option: "--privileged". It's still more secure than docker's one because you are limited by your user's capabilities.

bongobingo1 4y ago

I want to love SELinux, sounds great, I can see the real value in it. Tried to deploy some containers on an SE system and it would block everything. Ok expected, it actually has great tools for discovering, suggesting and creating rules to poke holes where needed, but it only suggests those things post-facto. So basically you're left deploying a container and waiting for something to break, then inspecting SE logs and patching rules in (and folding all that back into your ansible or whatever). Maybe this is OK if its your application and you can dump it on a staging environment and push it through your 100% coverage end to end test suite to capture all requirements, but if its a third party - or maybe your test coverage isn't quite where you want it to be - you're basically walking out on the rope bridge blind. Not sure there is really a way to solve that. Perhaps it there was a `pledge`/`unveil` like system where all requirements can be discovered up front... Otherwise it felt like yours stuck running in SEDisable or SEPermissive for months collecting data (after every deploy). Maybe I just missed an obvious route to disable swaths of SELinux for rootless containers - where it probably doesn't have as much of an application. Sorry Dan Walsh :(

yrro 4y ago
> Maybe I just missed an obvious route to disable swaths of SELinux for rootless containers Yeah you can put container_t into permissive mode: # semanage permissive -a container_t AVC denials will still be logged but the operations won't be denied.
- bongobingo1 4y ago
  It sounds like podman containers should automatically get that label so I'll give it another look, thanks!
  - yrro 4y ago
    Yeah, use ps -Z PID (from outside of a container) to check its label. Some other useful sources of info - the container_selinux man page tells you about container_t. And an index of Dan Walsh's blog posts about containers & SELinux can be found in the README of <https://github.com/containers/container-selinux https://github.com/containers/container-selinux>. And of course the RHEL documentation for creatign custom SELinux policies that inherit from container_t (for instance, I use it to allow processes within a container to read their certificates out of /etc/pki/tls which is normally forbidden. It's documented here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/using_selinux/creating-selinux-policies-for-containers_using-selinux#doc-wrapper https://access.redhat.com/documentation/en-us/red_hat_enterp...
spinachsalad 4y ago
> Maybe I just missed an obvious route to disable swaths of SELinux for rootless containers - where it probably doesn't have as much of an application. podman run --security-opt label=disable https://github.com/containers/podman/blob/main/troubleshooting.md#2-cant-use-volume-mount-get-permission-denied https://github.com/containers/podman/blob/main/troubleshooti... Note: Labeling can be disabled for all containers by setting label=false in the containers.conf(5) file. https://docs.podman.io/en/latest/markdown/podman-run.1.html#security-opt-option https://docs.podman.io/en/latest/markdown/podman-run.1.html#... But more secure way would be to add ":z" or ":Z" to volume and podman will auto-relabel source dir. Finally you can use nuclear option: "--privileged". It's still more secure than docker's one because you are limited by your user's capabilities.