Maybe I can try again, but it was frustrating enough to turn me away for a while.
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.... -> ip_unprivileged_port_start
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.
I did a quick test and it works ok for me to bind to low numbered ports just passing that param to podman run.
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 :(
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.
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>.
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_enterp...
podman run --security-opt label=disable
Note: Labeling can be disabled for all containers by setting label=false in the containers.conf(5) file.
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.