Description of problem: type=AVC msg=audit(1574861308.086:5257): avc: denied { getattr } for pid=25385 comm="certmonger-hapr" path="/usr/bin/podman" dev="sda1" ino=13127370 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.086:5259): avc: denied { read } for pid=25385 comm="certmonger-hapr" name="podman" dev="sda1" ino=13127370 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.086:5260): avc: denied { open } for pid=25385 comm="certmonger-hapr" path="/usr/bin/podman" dev="sda1" ino=13127370 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=1 Version-Release number of selected component (if applicable): openstack-selinux-0.8.20-0.20191125094339.a4fcc2c.el7.noarch How reproducible: Always Steps to Reproduce: 1. Deploy the undercloud|director using TLS and Certmonger internal CA 2. Check audit.log 3. Actual results: We get AVCs Expected results: We shouldn't get them Additional info: The following parameters are set in the undercloud.conf, in the DEFAULT section: generate_service_certificate = True certificate_generation_ca = local We might want to allow certmonger_t to read file patterns on container_share_t ? Not really sure of the potential implications.
Hm, after some more digging, we can get some more AVC related to that case: type=AVC msg=audit(1574861308.086:5257): avc: denied { getattr } for pid=25385 comm="certmonger-hapr" path="/usr/bin/podman" dev="sda1" ino=13127370 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.086:5258): avc: denied { execute } for pid=25385 comm="certmonger-hapr" name="podman" dev="sda1" ino=13127370 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.086:5259): avc: denied { read } for pid=25385 comm="certmonger-hapr" name="podman" dev="sda1" ino=13127370 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.086:5260): avc: denied { open } for pid=25385 comm="certmonger-hapr" path="/usr/bin/podman" dev="sda1" ino=13127370 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.086:5260): avc: denied { execute_no_trans } for pid=25385 comm="certmonger-hapr" path="/usr/bin/podman" dev="sda1" ino=13127370 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.184:5264): avc: denied { getattr } for pid=25385 comm="podman" path="/var/lib/containers/storage/libpod" dev="sda1" ino=192939394 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1574861308.184:5265): avc: denied { read write } for pid=25385 comm="podman" name="bolt_state.db" dev="sda1" ino=192989862 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.184:5265): avc: denied { open } for pid=25385 comm="podman" path="/var/lib/containers/storage/libpod/bolt_state.db" dev="sda1" ino=192989862 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.184:5266): avc: denied { lock } for pid=25385 comm="podman" path="/var/lib/containers/storage/libpod/bolt_state.db" dev="sda1" ino=192989862 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.184:5267): avc: denied { getattr } for pid=25385 comm="podman" path="/var/lib/containers/storage/libpod/bolt_state.db" dev="sda1" ino=192989862 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.195:5270): avc: denied { read write } for pid=25385 comm="podman" name="alive.lck" dev="tmpfs" ino=48119 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.195:5270): avc: denied { open } for pid=25385 comm="podman" path="/run/libpod/alive.lck" dev="tmpfs" ino=48119 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.195:5271): avc: denied { lock } for pid=25385 comm="podman" path="/run/libpod/alive.lck" dev="tmpfs" ino=48119 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.196:5272): avc: denied { getattr } for pid=25385 comm="podman" path="/run/libpod/alive" dev="tmpfs" ino=48436 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.196:5273): avc: denied { read write } for pid=25385 comm="podman" name="libpod_lock" dev="tmpfs" ino=59407 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_runtime_tmpfs_t:s0 tclass=file permissive=1 type=AVC msg=audit(1574861308.196:5273): avc: denied { open } for pid=25385 comm="podman" path="/dev/shm/libpod_lock" dev="tmpfs" ino=59407 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:container_runtime_tmpfs_t:s0 tclass=file permissive=1
Looking into the full logs, these mostly appear related to this command: proctitle=/bin/bash /usr/bin/certmonger-haproxy-refresh.sh reload external That seems to allow certmonger a lot of control over podman db etc... Is this about allowing certmonger to restart containers? I think that's the script in question: https://github.com/openstack/puppet-tripleo/blob/master/files/certmonger-haproxy-refresh.sh I wonder if we should use a domain transition to manage this rather than give certmonger direct rights over podman internals like that. I will run some tests locally but we may want to update the PR to handle reading puppet_etc_t separately, as that's read-only and more straightforward.
Hello Julie, Yes, certmonger needs to restart containers in order to ensure the app (haproxy in this case) is reloading the new certificate (although, in haproxy specific case, I'm not sure this is needed). You're indeed pointing to the right script - there are some others in the same location for different services, all of them being in containers. I don't know that "domain transition" thing (although I've probably seen them without knowing) - but it sounds like the right approach. I can therefore update my open PR in order to just take care of the puppet things (it's for the "hiera" calls in those scripts), and unlink it from this issue. Thank you for your investigations! C.
There are a couple of interfaces in container-selinux that could help us as well: container_runtime_exec(certmonger_t); -> resolves the container_runtime_exec denials container_admin(certmonger_t); -> resolves container_var_lib_t and container_var_run_t issues I would have thought using container_admin should be sufficient since that's pretty much what we want certmonger_t to do/be, however that doesn't resolve the last 2 container_runtime_tmpfs_t AVC denials. So potentially the following rules together would take care of everything: container_runtime_exec(certmonger_t); container_admin(certmonger_t); container_runtime_read_tmpfs_files(certmonger_t); allow certmonger_t container_runtime_tmpfs_t:file { write };
Created attachment 1640618 [details] audit.log Some considerations: - the way certmonger scripts refresh the container is wrong for podman - certmonger is called before any container is created and tries to reload the container - this doesn't create any issue, but it's pretty ugly - `podman cp' actually does `podman mount; cp; podman umount' which explains the calls to "mount" and other filesystem|block storage considerations Regarding the first consideration: the script calls "podman restart" and "podman kill --signal HUP", while the containers are managed by systemd - we probably want to update the script in order to call systemctl instead. This might change a bit the AVC. The attached file is for a run with "systemctl" calls.
Hello Julie, Would you be able to verify that BZ? It wouldn't make many sense if I verify it myself, since I provided the patches (well, you co-authored it ^^') Cheers, C.
I don't have the resources to check on a working environment, but I can do a sanity check and also have confidence based on the testing we did at the time. Verified using openstack-selinux-0.8.20-0.20191220123532.2f2c423.el8ost.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:0283