iptables-restore cannot read file from inside a container
Closed this issue · 6 comments
Hello,
With the same setup described in #205, with container-selinux-2.195.1-1.module_el8.8.0+1254+78119b6e.noarch
To reproduce the problem:
$ sudo podman run --pull=newer --rm -it --pid=host --privileged fedora:36
# nsenter -t 1 -a
# echo whatever > /tmp/hello
# /usr/sbin/iptables-restore --test /tmp/hello
Can't open /tmp/hello: Permission denied
AVC denial:
$ sudo ausearch -m avc -ts recent
----
time->Mon Mar 20 12:55:38 2023
type=PROCTITLE msg=audit(1679342138.151:13404): proctitle=2F7573722F7362696E2F69707461626C65732D726573746F7265002D2D74657374002F746D702F68656C6C6F
type=SYSCALL msg=audit(1679342138.151:13404): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffc4324d78e a2=80000 a3=0 items=0 ppid=155043 pid=155106 auid=169203 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=35 comm="iptables-restor" exe="/usr/sbin/xtables-nft-multi" subj=unconfined_u:system_r:iptables_t:s0 key=(null)
type=AVC msg=audit(1679342138.151:13404): avc: denied { read } for pid=155106 comm="iptables-restor" name="hello" dev="vda2" ino=31392461 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0
Syslog
Mar 20 12:56:16 testhost.example setroubleshoot[155141]: SELinux is preventing /usr/sbin/xtables-nft-multi from read access on the file hello. For complete SELinux messages run: sealert -l 655fe77c-165b-4f3a-b885-e4ce4d5b4f9b
Mar 20 12:56:16 testhost.example setroubleshoot[155141]: SELinux is preventing /usr/sbin/xtables-nft-multi from read access on the file hello.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that xtables-nft-multi should be allowed read access on the hello file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'iptables-restor' --raw | audit2allow -M my-iptablesrestor
# semodule -X 300 -i my-iptablesrestor.pp
Background: I want to use an ansible template to update iptables rules, using podman and the nsenter connection plugin, and use validation to avoid applying an invalid iptables file and breaking network access. It looks like e.g.
- name: Configure IPv4 firewall rules
template:
src: "iptables.j2"
dest: "/etc/sysconfig/iptables"
owner: "root"
group: "root"
mode: "0600"
validate: "/usr/sbin/iptables-restore --test %s"
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.
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.
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
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