CRIU related denials using Podman

[containers]

CRIU related denials using Podman

[adrianreber]

Using semodule -DB I also need:

allow iptables_t container_runtime_t:unix_dgram_socket { read write };
allow iptables_t container_runtime_t:unix_stream_socket { read write };

[rhatdan]

Did everything run without these Rules? I think most of these rules are leaked file descriptors.
Is CRIU Leaking these? Could it closeexec some of its file descriptors so other tools do not see the leaks.

[adrianreber]

Did everything run without these Rules?

Yes these rules are right now not necessary, but could lead to undesired effects.

CRIU uses iptables-restore to make sure that no network packets related to the process being checkpointed/restored are processed by the network stack. It could happen that during the time the process is frozen for checkpointing a network packet is accepted but it will never reach the process as it is being checkpointed and will be soon gone. For the other side of that network communication it will look like the network packet was accepted but there will never be an answer as the actual destination process never got that network packet.

For cases like TCP some re-transmission will probably happen, so that it might not be really problematic. The actual denials look like this:

type=AVC msg=audit(1553689187.416:761): avc:  denied  { append } for  pid=7067 comm="ip6tables-resto" path="/var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/restore.log" dev="sda1" ino=7272 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1553689187.416:762): avc:  denied  { append } for  pid=7067 comm="ip6tables-resto" path="/var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/restore.log" dev="sda1" ino=7272 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1553689187.417:763): avc:  denied  { read write } for  pid=7067 comm="ip6tables-resto" path="socket:[625545]" dev="sockfs" ino=625545 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1553689187.417:764): avc:  denied  { read } for  pid=7067 comm="ip6tables-resto" path="/var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/.criu.cgyard.RE2Ps9" dev="tmpfs" ino=559683 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:container_runtime_tmpfs_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1553689187.417:765): avc:  denied  { read } for  pid=7067 comm="ip6tables-resto" path="/var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/checkpoint" dev="sda1" ino=7274 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1553689187.417:766): avc:  denied  { append } for  pid=7067 comm="ip6tables-resto" path="/var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/restore.log" dev="sda1" ino=7272 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1553689187.417:767): avc:  denied  { read write } for  pid=7067 comm="ip6tables-resto" path="socket:[625545]" dev="sockfs" ino=625545 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1553689187.417:768): avc:  denied  { read write } for  pid=7067 comm="ip6tables-resto" path="socket:[559682]" dev="sockfs" ino=559682 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:container_runtime_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1553689187.417:769): avc:  denied  { ioctl } for  pid=7067 comm="ip6tables-resto" path="/proc/7041" dev="proc" ino=625565 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:system_r:container_t:s0:c749,c1020 tclass=dir permissive=0

I guess we could dontaudit these denials for now until we actually have a real problem with in-flight network packets.

[rhatdan]

The problem is leaked file descriptors.
The following AVC:

type=AVC msg=audit(1553689187.417:764): avc:  denied  { read } for  pid=7067 comm="ip6tables-resto" path="/var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/.criu.cgyard.RE2Ps9" dev="tmpfs" ino=559683 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:container_runtime_tmpfs_t:s0 tclass=dir permissive=0

Indicates ip6tables-restore is attempting to read /var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/.criu.cgyard.RE2Ps9 directory?

type=AVC msg=audit(1553689187.416:761): avc:  denied  { append } for  pid=7067 comm="ip6tables-resto" path="/var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/restore.log" dev="sda1" ino=7272 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=0

Indicates that ip6tables-restore is attemptint to append to /var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/restore.log

If when these files/directories were opened in CRI-U You did a CLOEXEC call, then the iptables commands would not see these open file descriptors and the avc's would not be generated.

[adrianreber]

Unfortunately I do not really know. I would say the access to those directories and files are legitimate but I am not sure about the leaked file descriptors. @avagin, any comments from you concerning the file descriptors.

[avagin]

Indicates that ip6tables-restore is attemptint to append to /var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/restore.log

iptables-restore writes logs into the criu log file. Is it a problem?

Indicates ip6tables-restore is attempting to read /var/lib/containers/storage/overlay-containers/21d484b4bfa40fcc9cfac8ee3771f82955f93beacd0ca6bb8ce93f9f5e1a3eda/userdata/.criu.cgyard.RE2Ps9 directory?

@adrianreber, here is a patch which prevents leaking file descriptors:
avagin/criu@07570fa

Could you try it out?

[adrianreber]

@avagin : that helps a lot. Thanks. This reduces the SELinux denials to log file accesses (dump.log and restore.log). So your CRIU patch reduces the required policies indeed. Thanks.

@rhatdan : So if I would label the CRIU log file restore.log also as c.MounLabel, just like the CRIU log file dump.log, in Podman, this would reduce the needed rules to:
allow iptables_t container_file_t:file append;
Can that rule be added to container-selinux?

[adrianreber]

Podman PR to also label restore.log correctly has been merged. So allow iptables_t container_file_t:file append; is the last to required policy to have Podman checkpoint/restore without any denials.

[rhatdan]

Should be allowed in container-selinux-2.98

[adrianreber]

@rhatdan Thanks a lot.