4 ms·

I really tried to use Podman, but I kept running into issues trying to get a rootless deployment on RHEL that used a protected port (53) and it gave me so much

I really tried to use Podman, but I kept running into issues trying to get a rootless deployment on RHEL that used a protected port (53) and it gave me so much trouble that I uninstalled Podman and installed Docker. Maybe I can try again, but it was frustrating enough to turn me away for a while.

BeefWellington 4y ago
If you want something as non-root to bind below 1024, there's a sysctl for it.[1] Docker bypasses this essentially because it uses root privs to set up the port forwarding rules. [1]: https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html https://www.kernel.org/doc/html/latest/networking/ip-sysctl.... -> ip_unprivileged_port_start
- sph 4y ago
  It's not enough in some cases, in a multi container pod (with `podman play kube`) I still got permission issues binding to privileged ports (which were permitted by the sysctl). There was some github issue about it. In my experience, if you need to bind to < 1024 ports, just run the container as root. Also if you want finer-grained control of host-side permissions of your mounts (i.e. map host uid 1000 to container uid 99). Otherwise rootless is fine.
  - BeefWellington 4y ago
    Note that that sysctl indicates it's namespace-specific, so it's possible it needs to be set for the application's namespace (maybe as well) via `--sysctl` on the podman command line. I did a quick test and it works ok for me to bind to low numbered ports just passing that param to podman run.
doublepg23 4y ago
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...

BeefWellington 4y ago

If you want something as non-root to bind below 1024, there's a sysctl for it.[1] Docker bypasses this essentially because it uses root privs to set up the port forwarding rules. [1]: https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html https://www.kernel.org/doc/html/latest/networking/ip-sysctl.... -> ip_unprivileged_port_start

sph 4y ago
It's not enough in some cases, in a multi container pod (with `podman play kube`) I still got permission issues binding to privileged ports (which were permitted by the sysctl). There was some github issue about it. In my experience, if you need to bind to < 1024 ports, just run the container as root. Also if you want finer-grained control of host-side permissions of your mounts (i.e. map host uid 1000 to container uid 99). Otherwise rootless is fine.
- BeefWellington 4y ago
  Note that that sysctl indicates it's namespace-specific, so it's possible it needs to be set for the application's namespace (maybe as well) via `--sysctl` on the podman command line. I did a quick test and it works ok for me to bind to low numbered ports just passing that param to podman run.

doublepg23 4y ago

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...