iptables-restore cannot read file from inside a container

[rptaylor]

iptables-restore cannot read file from inside a container

[rhatdan]

This is not a container-selinux issue but a selinux-policy issue.

I have no idea why /tmp/hello is being labeled admin_home_t (Label of /root).

The other question I have if the container is running as spc_t, then how do we transition to iptables_t.

[rptaylor]

Hmm .. unfortunately my reproduction was faulty, I must have accidentally reused a pre-existing /tmp/hello file that was created by an Ansible template task. I think the reason it has that label must be related to how Ansible sets it up starting from /root/.ansible:

TASK [Test] *****************************************************************************************************************************************************************
task path: /play.yml:4
fatal: [testhost]: FAILED! => {"changed": false, "checksum": "c30b59e5e5af2cf5840483b7ed8932d1bb1a44e3", "exit_status": 1, "msg": "failed to validate", "stderr": "Can't open /root/.ansible/tmp/ansible-tmp-1679430906.8702123-172253-47066720203546/source: Permission denied\n", "stderr_lines": ["Can't open /root/.ansible/tmp/ansible-tmp-1679430906.8702123-172253-47066720203546/source: Permission denied"], "stdout": "", "stdout_lines": []}

So maybe it is an Ansible-related issue ... I will take a closer look. Thanks.

[rptaylor]

ansible/ansible#80269

[rptaylor]

The "hello" file being in /tmp is immaterial I think. Ansible prepares content in ~/.ansible/tmp which is in the root home dir in this situation anyway.

Here are some cases that can be easily reproduced without Ansible.
Starting off

[centos@centos8 ~]$ sudo dnf -y install podman iptables
[centos@centos8 ~]$ sudo podman run --pull=newer --rm -it --pid=host --privileged fedora:37
[root@47946f8aefce /]# nsenter -t 1 -a
[root@centos8 /]# 

And then, if writing in /tmp or /etc it works:

[root@centos8 /]# echo whatever > /tmp/tmptest; ls -lZ /tmp/tmptest; /usr/sbin/iptables-restore --test /tmp/tmptest
-rw-r--r--. 1 root root unconfined_u:object_r:tmp_t:s0 9 Mar 23 23:02 /tmp/tmptest
iptables-restore: line 1 failed
[root@centos8 /]# echo whatever > /etc/etctest; ls -lZ /etc/etctest; /usr/sbin/iptables-restore --test /etc/etctest
-rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 9 Mar 23 23:06 /etc/etctest
iptables-restore: line 1 failed

This one really baffles me, it fails if writing in a user home - but there is no AVC denial nor a setroubleshoot SELinux syslog error message! Is SELinux silently blocking it?

[root@centos8 /]# echo whatever > /home/centos/hometest; ls -lZ /home/centos/hometest; /usr/sbin/iptables-restore --test /home/centos/hometest
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 9 Mar 23 23:03 /home/centos/hometest
Can't open /home/centos/hometest: Permission denied

Anyway the relevant case is still writing in /root

[root@centos8 /]# echo whatever > /root/roottest; ls -lZ /root/roottest; /usr/sbin/iptables-restore --test /root/roottest
-rw-r--r--. 1 root root unconfined_u:object_r:admin_home_t:s0 9 Mar 23 23:03 /root/roottest
Can't open /root/roottest: Permission denied

with this denial:

----
time->Thu Mar 23 23:03:12 2023
type=PROCTITLE msg=audit(1679612592.358:710): proctitle=2F7573722F7362696E2F69707461626C65732D726573746F7265002D2D74657374002F726F6F742F726F6F7474657374
type=SYSCALL msg=audit(1679612592.358:710): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffd9a4dc79f a2=80000 a3=0 items=0 ppid=11825 pid=11868 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=6 comm="iptables-restor" exe="/usr/sbin/xtables-nft-multi" subj=unconfined_u:system_r:iptables_t:s0 key=(null)
type=AVC msg=audit(1679612592.358:710): avc:  denied  { read } for  pid=11868 comm="iptables-restor" name="roottest" dev="vda1" ino=4224539 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0

The other question I have if the container is running as spc_t, then how do we transition to iptables_t.

I don't know , is there anything I can do to determine that?

This is not a container-selinux issue but a selinux-policy issue.

My apologies. I have already opened ansible/ansible#80269 and ansible-collections/community.docker#599 ; I don't know enough about SELinux to understand where the problem is.
Anyway maybe I will try opening a selinux-policy issue but any advice you have would be greatly appreciated @rhatdan

[rhatdan]

Try this and see if it works.

sudo podman run --pull=newer --security-opt label=type:unconfined_t --rm -it --pid=host --privileged fedora:37

[rptaylor]

Aha that works, thanks! It also avoids some of the issues in #205