container_init_t does not possess ptrace process context

[robbmanes]

container_init_t does not possess ptrace process context

[rhatdan]

Fixed in #279

[TomSweeneyRedHat]

@rhatdan this has a rather hot Jira Card assigned to it. If you could PTAL as soon as you can, I'd appreciate it.

[rhatdan]

allow container_t container_t:capability { audit_write chown dac_read_search fowner kill mknod net_admin net_bind_service net_raw setfcap setgid setpcap setuid sys_chroot };

allow container_init_t container_init_t:capability { audit_write chown dac_read_search fowner kill mknod net_bind_service net_raw setfcap setgid setpcap setuid sys_chroot };

Neither container_t or container_init_t have CAP_SYS_PTRACE. You can add this by launching the container with --cap-add CAP_SYS_PTRACE

[rhatdan]

Actually I am wrong.

[rhatdan]

$ sesearch -A -s container_init_t -c capability -p sys_ptrace
allow container_init_t container_init_t:capability { audit_control dac_override fsetid ipc_lock ipc_owner lease linux_immutable net_admin net_broadcast sys_admin sys_boot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; [ virt_sandbox_use_all_caps ]:True
$ sesearch -A -s container_t -c capability -p sys_ptrace
allow container_t container_t:capability { audit_control dac_override fsetid ipc_lock ipc_owner lease linux_immutable net_broadcast sys_admin sys_boot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; [ virt_sandbox_use_all_caps ]:True

I would guess our system is running without this boolean turned on.

[robbmanes]

I've reproduced this on RHEL9.2 and Fedora 38, both fresh installs.

# uname -r
5.14.0-284.25.1.el9_2.x86_64

# rpm -q container-selinux
container-selinux-2.205.0-1.el9_2.noarch

Using the boolean specified, which is indeed set to true by default:

# setsebool virt_sandbox_use_all_caps=true

# getsebool virt_sandbox_use_all_caps
virt_sandbox_use_all_caps --> on

# podman run -d --name systemd --rm registry.redhat.io/ubi8-init

# podman inspect systemd | jq '.[].State.Pid'
1252077

# ps -Z 1252077
LABEL                               PID TTY      STAT   TIME COMMAND
system_u:system_r:container_init_t:s0:c700,c702 1252077 ? Ss   0:00 /sbin/init

# podman exec -it systemd yum install strace -y

# /bin/nsenter -Z -m -n -p -t 1252077 strace ls
strace: test_ptrace_get_syscall_info: PTRACE_TRACEME: Permission denied
strace: ptrace(PTRACE_TRACEME, ...): Permission denied
+++ exited with 1 +++

The ptrace still fails, unless SELinux is disabled:

# setenforce 0

# /bin/nsenter -Z -m -n -p -t 1252077 strace ls
execve("/usr/bin/ls", ["ls"], 0x7ffea8321230 /* 23 vars */) = 0
[...]
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

Capabilities granted to the container:

# podman inspect systemd | jq '.[]|[.BoundingCaps, .EffectiveCaps]'
[
  [
    "CAP_CHOWN",
    "CAP_DAC_OVERRIDE",
    "CAP_FOWNER",
    "CAP_FSETID",
    "CAP_KILL",
    "CAP_NET_BIND_SERVICE",
    "CAP_SETFCAP",
    "CAP_SETGID",
    "CAP_SETPCAP",
    "CAP_SETUID",
    "CAP_SYS_CHROOT"
  ],
  [
    "CAP_CHOWN",
    "CAP_DAC_OVERRIDE",
    "CAP_FOWNER",
    "CAP_FSETID",
    "CAP_KILL",
    "CAP_NET_BIND_SERVICE",
    "CAP_SETFCAP",
    "CAP_SETGID",
    "CAP_SETPCAP",
    "CAP_SETUID",
    "CAP_SYS_CHROOT"
  ]
]

Likewise, container_t contexts do not have this issue:

# podman inspect sleeper | jq '.[].State.Pid'
1254081

# ps -Z 1254081
LABEL                               PID TTY      STAT   TIME COMMAND
system_u:system_r:container_t:s0:c552,c601 1254081 ? Ss   0:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep infinity

It still works by default with SELinux enabled:

# podman exec -it sleeper yum install strace -y

# /bin/nsenter -Z -m -n -p -t 1254081 strace ls
execve("/usr/bin/ls", ["ls"], 0x7ffded966400 /* 23 vars */) = 0
[...]
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

With the same capabilities as the systemd container:

# podman inspect sleeper | jq '.[]|[.BoundingCaps, .EffectiveCaps]'
[
  [
    "CAP_CHOWN",
    "CAP_DAC_OVERRIDE",
    "CAP_FOWNER",
    "CAP_FSETID",
    "CAP_KILL",
    "CAP_NET_BIND_SERVICE",
    "CAP_SETFCAP",
    "CAP_SETGID",
    "CAP_SETPCAP",
    "CAP_SETUID",
    "CAP_SYS_CHROOT"
  ],
  [
    "CAP_CHOWN",
    "CAP_DAC_OVERRIDE",
    "CAP_FOWNER",
    "CAP_FSETID",
    "CAP_KILL",
    "CAP_NET_BIND_SERVICE",
    "CAP_SETFCAP",
    "CAP_SETGID",
    "CAP_SETPCAP",
    "CAP_SETUID",
    "CAP_SYS_CHROOT"
  ]
]

So I don't think it's a boolean being present or not, assuming my reproduction steps are sane. Can you easily reproduce it like I did above?

[rhatdan]

$ sesearch -A -s container_init_t -c capability -p sys_ptrace
allow container_init_t container_init_t:capability { audit_control dac_override fsetid ipc_lock ipc_owner lease linux_immutable net_admin net_broadcast sys_admin sys_boot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; [ virt_sandbox_use_all_caps ]:True

$ rpm -q container-selinux
container-selinux-2.222.0-1.fc39.noarch

Could you try with podman exec rather then nsenter.

BUT I think the real issue might be that you are being blocked by Capabilities, not SElinux.

Could you run the initial container with --cap-add SYS_PTRACE.

[robbmanes]

BUT I think the real issue might be that you are being blocked by Capabilities, not SElinux.

I don't think that could be, unless I am mistaken here about the context in which this is executed - I disabled SELinux and it worked as-is, as per my reproduction steps in #273 (comment) and at the beginning of this issue.

Could you try with podman exec rather then nsenter.

Appears to be the same result if I do podman exec, and continues to work if I pet SELinux in permissive:

# getenforce
Enforcing

# podman run -d --name systemd --rm registry.redhat.io/ubi8-init

# podman exec -it systemd yum install strace -y

# podman exec -it systemd strace ls
strace: test_ptrace_get_syscall_info: PTRACE_TRACEME: Permission denied
strace: ptrace(PTRACE_TRACEME, ...): Permission denied
+++ exited with 1 +++

# setenforce 0

# podman exec -it systemd strace ls
execve("/usr/bin/ls", ["ls"], 0x7ffe948ff310 /* 4 vars */) = 0
[...]
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

Could you run the initial container with --cap-add SYS_PTRACE.

The ptrace syscall continues to be denied.

# podman run -d --name systemd --cap-add=SYS_PTRACE --rm registry.redhat.io/ubi8-init

# podman exec -it systemd yum install strace -y

# podman exec -it systemd strace ls
strace: test_ptrace_get_syscall_info: PTRACE_TRACEME: Permission denied
strace: ptrace(PTRACE_TRACEME, ...): Permission denied
+++ exited with 1 ++

# getenforce
Enforcing

# setenforce 0

# getenforce
Permissive

# podman exec -it systemd strace ls
execve("/usr/bin/ls", ["ls"], 0x7ffe5cf03690 /* 4 vars */) = 0
[...]
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

I believe that places this as something particular to SELinux, which I believe to be, at least to my understanding, a difference in container_init_t process contexts, no? I am not very versed on SELinux as it applies to processes.

Can you reproduce this with the steps I've provided? My end customer can as well on RHEL, I did Fedora and the upstream packages just for completeness. Thanks.

[rhatdan]

Please attach the AVC messages.

[robbmanes]

Please attach the AVC messages.

type=SYSCALL msg=audit(1696919928.678:426519): arch=c000003e syscall=101 success=no exit=-13 a0=4206 a1=7e a2=0 a3=0 items=0 ppid=1454981 pid=1454985 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=45 comm="strace" exe="/usr/bin/strace" subj=system_u:system_r:container_init_t:s0:c692,c886 key=(null)�ARCH=x86_64 SYSCALL=ptrace AUID="rmanes" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=OBJ_PID msg=audit(1696919928.678:426519): opid=1454986 oauid=1000 ouid=0 oses=45 obj=system_u:system_r:container_init_t:s0:c692,c886 ocomm="strace"�OAUID="rmanes" OUID="root"
type=AVC msg=audit(1696919928.678:426520): avc:  denied  { ptrace } for  pid=1454987 comm="strace" scontext=system_u:system_r:container_init_t:s0:c692,c886 tcontext=system_u:system_r:container_init_t:s0:c692,c886 tclass=process permissive=0
type=SYSCALL msg=audit(1696919928.678:426520): arch=c000003e syscall=101 success=no exit=-13 a0=0 a1=0 a2=0 a3=0 items=0 ppid=1454985 pid=1454987 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=45 comm="strace" exe="/usr/bin/strace" subj=system_u:system_r:container_init_t:s0:c692,c886 key=(null)�ARCH=x86_64 SYSCALL=ptrace AUID="rmanes" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=AVC msg=audit(1696919928.678:426521): avc:  denied  { ptrace } for  pid=1454988 comm="strace" scontext=system_u:system_r:container_init_t:s0:c692,c886 tcontext=system_u:system_r:container_init_t:s0:c692,c886 tclass=process permissive=0
type=SYSCALL msg=audit(1696919928.678:426521): arch=c000003e syscall=101 success=no exit=-13 a0=0 a1=0 a2=0 a3=0 items=0 ppid=1454985 pid=1454988 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=45 comm="strace" exe="/usr/bin/strace" subj=system_u:system_r:container_init_t:s0:c692,c886 key=(null)�ARCH=x86_64 SYSCALL=ptrace AUID="rmanes" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"

[slcmpunk]

I can reproduce this as well on my RHEL9.2 system:

	[root@rhel9 ~]# rpm -q container-selinux
	container-selinux-2.205.0-1.el9_2.noarch
	[root@rhel9 ~]# rpm -q podman
	podman-4.4.1-12.el9_2.x86_64

	[root@rhel9 ~]#  podman run -d --name systemd --rm registry.redhat.io/ubi8-init
	Trying to pull registry.redhat.io/ubi8-init:latest...
	Getting image source signatures
	Checking if image destination supports signatures
	Copying blob d0c0191a2d40 done  
	Copying blob f992cb38fce6 done  
	Copying config b5452e5e96 done  
	Writing manifest to image destination
	Storing signatures
	f46e3a9dbf8c14496a5461ea3523278243175603b031b3727db3fc4883b86cc5

	[root@rhel9 ~]# podman inspect systemd | jq '.[].State.Pid'
	3342481
	[root@rhel9 ~]# ps -Z 3342481
	LABEL                               PID TTY      STAT   TIME COMMAND
	system_u:system_r:container_init_t:s0:c570,c783 3342481 ? Ss   0:00 /sbin/init
	[root@rhel9 ~]# podman exec -it systemd yum install strace -y --quiet
		                                                 
	Installed: strace-5.18-2.el8.x86_64                                                                                                                                                                                                                            

	[root@rhel9 ~]# /bin/nsenter -Z -m -n -p -t 3342481 strace ls
	strace: test_ptrace_get_syscall_info: PTRACE_TRACEME: Permission denied
	strace: ptrace(PTRACE_TRACEME, ...): Permission denied
	+++ exited with 1 +++
	[root@rhel9 ~]# setenforce 0
	[root@rhel9 ~]# /bin/nsenter -Z -m -n -p -t 3342481 strace ls
	execve("/usr/bin/ls", ["ls"], 0x7ffdcfbdb7c0 /* 30 vars */) = 0
	brk(NULL)                               = 0x55a30ea32000
	~
	~
	~
	close(1)                                = 0
	close(2)                                = 0
	exit_group(0)                           = ?
	+++ exited with 0 +++

[rhatdan]

I got it.

[robbmanes]

Excellent, thank you @rhatdan; I built a new container-selinux package with commit 4b384f0 in it and can confirm it solves the problem. Much appreciated.