perezjasonr
commented
3 years ago Ok so...this is probably a crucial update. but I learned about the append arg that udica has, after the append, it seems to have gotten past this. It looked like this:
ausearch -m avc -i > avcfile
udica --append-rules avcfile -j chown-container2.json chown-container-data-dirpolicy now looks like this:
cat chown-container-data-dir.cil
(block chown-container-data-dir
(blockinherit container)
(allow process var_lib_t ( dir ( add_name create getattr ioctl lock open read remove_name rmdir search setattr write )))
(allow process var_lib_t ( file ( append create getattr ioctl lock map open read rename setattr unlink write )))
(allow process var_lib_t ( sock_file ( append getattr open read write )))
(allow process var_lib_t ( dir ( add_name create getattr ioctl lock open read remove_name rmdir search setattr write )))
(allow process var_lib_t ( file ( append create getattr ioctl lock map open read rename setattr unlink write )))
(allow process var_lib_t ( sock_file ( append getattr open read write )))
(allow process var_lib_t ( dir ( add_name create getattr ioctl lock open read remove_name rmdir search setattr write )))
(allow process var_lib_t ( file ( append create getattr ioctl lock map open read rename setattr unlink write )))
(allow process var_lib_t ( sock_file ( append getattr open read write )))
(allow process container_var_lib_t ( dir ( setattr )))avc denials have now moved on to a new denial and is back to container_t source (and the logs of the first container claim to have been successful).
If is all expected behavior, meaning, initial udica run may not catch everything, and a possible append using avc is standard procedure then I suppose this can be closed?
For now I will continue with these steps for the next denied container.
vmojzis
Describe the bug
Udica could possibly be missing some attributes/rules for a given policy generation. I ran udica for a given container (in this case I was trying it for rook/ceph) that was getting avc denials, then updated the container to have the type, but it is still getting denied. Audit2allow still shows a potential rule that might have allowed the container to do what it was trying to do. explained below:
To Reproduce Steps to reproduce the behavior:
attempt to install rook-ceph, in this case I am working on the init-container known as chown-container-data-dir for one of the deployments which is being denied (there are others but this is the first one being denied).
find the crashing container, inspect and run udica against it. Here is the resulting policy generated:
follow the instructions provided by udica in my case:
semodule -i chown-container-data-dir.cil /usr/share/udica/templates/base_container.cilthen update the container to use the new type/label.even with the new policy in place, the container is still being denied:
notice the scontext:
scontext=system_u:system_r:chown-container-data-dir.process:s0:c82,c419Expected behavior the container with the policy in place, and with the type set to proper type it should get past the denial. this of course would mean (according to my understanding) it would not miss any needed allow rules (see below)
Additional context
These outputs might be useful lets see that specific source and target with class dir:
and audit2allow "thinks" an extra setattr is needed, only care about the first section specific to chown-container-data-dir.process, as I don't want to give entire container_t setattr obviously:
possibly some significant sections from the inspect json:
let me know if anything else might be useful, like the full inspect json.
Or if I missed something obvious...I apologize but thank you for your consideration.