A mounted directory on a container with label type container_file_t can be accessed by a process running in a different domain

[ZaiBouz]

This is a repost from a previous discussion, as I still haven't found an answer

I was running some tests to see how effective SELinux is in containerized environments,and I came upon an irregular behavior, and I can't understand why it's happening. Let's say in the case where someone somehow gave the wrong permissions to a mounted directory (rwxrwxrwx) on a container, in my case I'm using Podman, this would mean that in a system where only DAC checks are performed, anyone can access and modify this directory, but if SELinux was enabled and running in enforcing mode, and the directory was correctly labeled with the "container_file_t" context associated with containers, this would mean that even if the DAC allows access, the SELinux would allow only processes running in the appropriate domain (container_t) to have access to it. But in my case, SELinux doesn't block the access.

So here's how I recreated this test

1. First thing I changed Selinux mode to enforcing
2. I created a home directory /home/TestDir
3. Then I chmod 777 /home/TestDir so that all users (different SELinux profiles) can access this directory
4. Created a container (in root mode), and bind mounted the created directory with the SELinux flag :Z
   podman run -dit -v /home/TestDir:/data:Z registry.access.redhat.com/ubi8
5. The /home/TestDir directory got the appropriate Selinux type: system_u:object_r:container_file_t:s0:c236,c488
6. Logged with SSH to another user JohnDoe. It is associated with a user_u SELinux user: user_u:user_r:user_t:s0
7. The processes initiated with this user are all running in the user_t domain
8. I accessed the /home/TestDir and created a test file ==> It worked !! No error was generated
9. No error logged in journalctl ou audit.log

Now it seems that even though I'm running SELinux in enforcing mode, a home directory ( That i chmod to 777 purposely ) with a label type container_file_t can be accessed with processes running in different domains with no problem. So it seems as if the MAC control in this case is as permissive as the DAC.
I tried to modify the directory with other processes running in staff_t and guest_t domains and it works.

When I check the selinux rules that allow access to container files I found these entries :

allow userdomain container_file_t:dir { add_name getattr ioctl lock open read remove_name search write };
allow userdomain container_file_t:file { append create getattr ioctl link lock open read rename setattr unlink watch watch_reads write };
allow userdomain container_file_t:lnk_file { append create getattr ioctl link lock read rename setattr unlink watch watch_reads write };

As I understand the userdomain encompasses a collection of related user domains, typically those associated with typical user-level processes like user_t for example. So this would explain why a process running in user_t would be able to manage the directory. But I tried to modify it with a process running in guest_t domain and SELinux allows it too ( A use can only read files created by other users, but he can still remove and inject files ).

My questions are :

• Did I miss something in the SELinux configuration when running Podman, or is this a normal behavior and there's a logical explanation for it ?
• What is the best method to secure and protect a container (volume or mounted directory) if the host machine got compromised ?

Thanks in advance