Questions regarding generated CIL of /home/<user> subdirectories

[ca-hu]

Hi, I have two questions regarding the generated cil file for a container with bind mount: -v /home/myuser:/home:myuser:rw (using podman).

The generated container json looks like this:

...
               {
                    "Type": "bind",
                    "Source": "/home/myuser",
                    "Destination": "/home/myuser",
                    "Driver": "",
                    "Mode": "",
                    "Options": [
                         "rbind"
                    ],
                    "RW": true,
                    "Propagation": "rprivate"
               },
...

First question:

In this usecase with /home/myuser, the blockinherit home_rw_container is not getting added because subdirectories of /home are not matched i think:

udica/udica/policy.py

Line 362 in 7fa8143

if item["Source"] == HOME_CONTAINER and item["RW"] is True:

Is this intended or a bug?

Second question:

The container-selinux udica templates and udica are only generating rules for user_home_t, user_home_dir_t,home_root_t and not for other home directory types, e.g. cache_home_t or other types that have the user_home_type attribute.

Also for this, is this intended or a bug?

Thanks a lot :)

[vmojzis]

Hi, I'm not the original developer, so can't be sure, but I believe both are intentional (so as not to add more permission than necessary). Specifically in the first case, udica will browse "/home/myuser" (provided it has access to the path) and include access to all labels it encounters in the final policy.
If you still encounter AVCs, you should be able to deal with them using the "--append-rules" option.
If you believe that udica's behavior should be changed, please describe your use-case (ideally including the container json, or a reproducer) and what you wish udica to do differently.

[ca-hu]

Thanks for the reply :)

Specifically in the first case, udica will browse "/home/myuser" (provided it has access to the path) and include access to all labels it encounters in the final policy.

Okay i think it is a bug then, because I would assume that when i create folders under /home/test like this

test@localhost:~$ mkdir -Z my_test_folder
test@localhost:~$ ls -alZ my_test_folder/
insgesamt 4
drwxr-xr-x. 2 test test unconfined_u:object_r:user_home_t:s0        6 14. Mär 10:59 .
drwx------. 6 test test unconfined_u:object_r:user_home_dir_t:s0 4096 14. Mär 10:59 ..
test@localhost:~$ matchpathcon /home/test/my_test_folder
/home/test/my_test_folder	unconfined_u:object_r:user_home_t:s0

And then I create a policy with udica like this:

test@localhost:~$ podman run -v /home/test:/home/test -it fedora bash
[root@d1298659501e /]# ls -alZ /home/test/
ls: cannot open directory '/home/test/': Permission denied
[root@d1298659501e /]# exit
exit
...
test@localhost:~$ podman inspect 36cec1026f26 > container.json
test@localhost:~$ sudo udica -j container.json  my_container
[sudo] Passwort für test: 

Policy my_container created!

Please load these modules using: 
# semodule -i my_container.cil /usr/share/udica/templates/base_container.cil

Restart the container with: "--security-opt label=type:my_container.process" parameter
test@localhost:~$ sudo semodule -i my_container.cil /usr/share/udica/templates/base_container.cil
...

and run with the policy, i should be able to see the content of /home/test/my_test_folder

test@localhost:~$ podman run --security-opt label=type:my_container.process -v /home/test:/home/test -it fedora bash
[root@e7241d1dfa1d /]# ls -alZ /home/test
ls: cannot access '/home/test/.bash_logout': Permission denied
ls: cannot access '/home/test/.bash_profile': Permission denied
ls: cannot access '/home/test/.bashrc': Permission denied
ls: cannot access '/home/test/.bash_history': Permission denied
ls: cannot access '/home/test/my_container.cil': Permission denied
ls: cannot access '/home/test/container.json': Permission denied
total 4
drwx------. 6 root root unconfined_u:object_r:user_home_dir_t:s0        4096 Mar 14 09:59 .
drwxr-xr-x. 1 root root system_u:object_r:container_file_t:s0:c251,c723   18 Mar 14 10:04 ..
-?????????? ? ?    ?    ?                                                  ?            ? .bash_history
-?????????? ? ?    ?    ?                                                  ?            ? .bash_logout
-?????????? ? ?    ?    ?                                                  ?            ? .bash_profile
-?????????? ? ?    ?    ?                                                  ?            ? .bashrc
drwx------. 3 root root unconfined_u:object_r:cache_home_t:s0             24 Mar 14 09:53 .cache
drwx------. 2 root root unconfined_u:object_r:config_home_t:s0             6 Mar 14 09:52 .config
drwx------. 3 root root unconfined_u:object_r:gconf_home_t:s0             19 Mar 14 09:53 .local
-?????????? ? ?    ?    ?                                                  ?            ? container.json
-?????????? ? ?    ?    ?                                                  ?            ? my_container.cil
drwxr-xr-x. 2 root root unconfined_u:object_r:user_home_t:s0               6 Mar 14 09:59 my_test_folder
[root@e7241d1dfa1d /]# ls -alZ /home/test/my_test_folder
ls: cannot open directory '/home/test/my_test_folder': Permission denied

But that does not work, because the generated cil does not include blockinherit home_rw_container and also it seems udica does not traverse the /home/test folder:

(block my_container
    (blockinherit container)
    (allow process process ( capability ( chown dac_override fowner fsetid kill net_bind_service setfcap setgid setpcap setuid sys_chroot ))) 

    (allow process user_home_dir_t ( dir ( add_name create getattr ioctl lock open read remove_name rmdir search setattr write ))) 
    (allow process user_home_dir_t ( file ( append create getattr ioctl lock map open read rename setattr unlink write ))) 
    (allow process user_home_dir_t ( fifo_file ( getattr read write append ioctl lock open ))) 
    (allow process user_home_dir_t ( sock_file ( append getattr open read write ))) 
)

One of our engineers found this on opensuse tumbleweed, but the test above is with a fedora rawhide VM. The usecase is basically that some script needs to be run in a container but needs access to home directories of one user only (not whole /home).

see the container.json

[ca-hu]

more specifically, they additionally needed access to some dot files e.g. /home/test/.cache, which is labelled cache_home_t, so even using -v /home:/home leading to udica adding blockinherit home_rw_container is not enough because there is no traversal of potential labels under /home/test. That is why i am asking about why the udica templates in container-selinux are not using the user_home_type :D

e.g.

test@localhost:~$  podman run -v /home:/home -it fedora bash
test@localhost:~$  podman inspect 11a79fdfc95c > container2.json
test@localhost:~$ sudo udica -j container2.json  my_container2
test@localhost:~$  sudo semodule -i my_container2.cil /usr/share/udica/templates/{base_container.cil,home_container.cil}
test@localhost:~$  podman run --security-opt label=type:my_container2.process -v /home:/home -it fedora bash
[root@98f2f9e77e12 /]# ls -al /home/test/.cache
ls: cannot open directory '/home/test/.cache': Permission denied
[root@98f2f9e77e12 /]# ls -al /home/test/.config
ls: cannot open directory '/home/test/.config': Permission denied
[root@98f2f9e77e12 /]# ls -al /home/test/my_test_folder/
total 4
drwxr-xr-x. 2 root root    6 Mar 14 09:59 .
drwx------. 6 root root 4096 Mar 14 10:28 ..