sh# rpm -q podman systemd kernel selinux-policy container-selinux
podman-1.6.4-0.39.dev.gitb29928f.fc32.x86_64
systemd-244~rc1-1.fc32.x86_64
kernel-5.4.0-0.rc5.git0.1.fc32.x86_64
kernel-5.4.0-2.fc32.x86_64
selinux-policy-3.14.5-16.fc32.noarch
container-selinux-2.123.0-0.1.dev.git661a904.fc32.noarch

How to reproduce
1. dnf install -y podman
2. mkdir test
3. cat > test/Dockerfile  <<EOF
FROM registry.fedoraproject.org/fedora:31

RUN groupadd -g 288 kdcproxy ; useradd -u 288 -g 288 -c 'KDC Proxy User' -d '/var/lib/kdcproxy' -s '/sbin/nologin' kdcproxy

RUN ln -s /bin/false /usr/sbin/systemd-machine-id-setup
RUN dnf install -y podman
EOF
4. podman build -t test -f test/Dockerfile


I can reproduce AVCs just with cgroupsv2 which is default.


Please move to different component if it is not related to podman




BTW I can see more AVCs after running full test-suite on rawhide

sh# journalctl | grep " AVC avc" | audit2allow


#============= container_t ==============
allow container_t proc_t:filesystem associate;
allow container_t self:dir add_name;

#============= init_t ==============
allow init_t NetworkManager_t:process setsched;
allow init_t auditd_t:process setsched;
allow init_t chronyd_t:process setsched;
allow init_t container_runtime_t:process setsched;
allow init_t getty_t:process setsched;
allow init_t gssproxy_t:process setsched;
allow init_t iptables_t:process setsched;
allow init_t sshd_t:process setsched;
allow init_t sssd_t:process setsched;
allow init_t syslogd_t:process setsched;
allow init_t system_dbusd_t:process setsched;
allow init_t systemd_logind_t:process setsched;
allow init_t udev_t:process setsched;
allow init_t unconfined_service_t:process setsched;
allow init_t unconfined_t:process setsched;

Actually it is quite interesting case.

I cannot reproduce AVCs when service is deployed on host and not in container (just pdman and cgroupsv2)

Other way how to get rid of AVCs is to downgrade version of systemd to systemd-243.4-1.fc32.x86_64.rpm

Could you explain what (and why) systemd is trying to do ?

This is definitely not caused by Podman, and since we have AVCs about init basically setsched on every process that it launches, it should be fixed in selinux-policy.

(In reply to Daniel Walsh from comment #4)
> This is definitely not caused by Podman, and since we have AVCs about init
> basically setsched on every process that it launches, it should be fixed in
> selinux-policy.

But it is triggered by podman/crun (as I mentioned in comment2).
We need to find out why AVCs are not visible when service is running directly in host.
Allowing denials without knowing the reason is not ideal.

Maybe podman/crun modify something on host which makes systemd doing some magic.

I would say it might be more related to crun because I cannot see AVCs with latest rawhide + podman + cgroupsv1

For whatever reason, I can't reproduce this. What syscall is selinux rufusing: sched_setscheduler?
Could someone who can reproduce the issue show what 'strace -y -k -e ... -p 1' is showing?

When using the reproducer from comment #1, I'm getting the following failure:
$ podman build -t test -f test/Dockerfile
STEP 1: FROM registry.fedoraproject.org/fedora:31
STEP 2: RUN groupadd -g 288 kdcproxy ; useradd -u 288 -g 288 -c 'KDC Proxy User' -d '/var/lib/kdcproxy' -s '/sbin/nologin' kdcproxy
WARN[0000] exit status 1                                
ERRO[0000] container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/dev\\\" to rootfs \\\"/var/tmp/buildah174124531/mnt/rootfs\\\" at \\\"/dev\\\" caused \\\"invalid argument\\\"\"" 
container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/dev\\\" to rootfs \\\"/var/tmp/buildah174124531/mnt/rootfs\\\" at \\\"/dev\\\" caused \\\"invalid argument\\\"\""
error running container: error creating container for [/bin/sh -c groupadd -g 288 kdcproxy ; useradd -u 288 -g 288 -c 'KDC Proxy User' -d '/var/lib/kdcproxy' -s '/sbin/nologin' kdcproxy]: : exit status 1
Error: error building at STEP "RUN groupadd -g 288 kdcproxy ; useradd -u 288 -g 288 -c 'KDC Proxy User' -d '/var/lib/kdcproxy' -s '/sbin/nologin' kdcproxy": error while running runtime: exit status 1

I have no idea what that means.

$ rpm -q podman systemd selinux-policy container-selinux; uname -r
podman-1.6.4-0.39.dev.gitb29928f.fc32.x86_64
systemd-244-1.fc32.x86_64
selinux-policy-3.14.5-18.fc32.noarch
container-selinux-2.123.0-0.3.dev.git0b25a4a.fc32.noarch
5.4.0-0.rc2.git1.1.fc32.x86_64

With kernel 5.4.0-2.fc32.x86_64, the reproducer finishes fine, without any issues or AVC logs.
Sorry, I have no idea what operation is refused.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> With kernel 5.4.0-2.fc32.x86_64, the reproducer finishes fine, without any
> issues or AVC logs.
> Sorry, I have no idea what operation is refused.

Sorry, I forgot to verify my test-case on minimal rawhide machine.
(but after additional investigarion, it seems to be related to running systemd in container and (setsebool -P container_manage_cgroup 1))

here is output of strace
sh# strace -tt -yy -p 1

10:42:45.216064 write(23</sys/fs/cgroup/machine.slice/pids.max>, "max\n", 4) = 4
10:42:45.216085 close(23</sys/fs/cgroup/machine.slice/pids.max>) = 0
10:42:45.216109 setxattr("/sys/fs/cgroup/machine.slice", "trusted.invocation_id", "1f6c6f9acc1f45709f4dc9b0d42955e1", 32, 0) = 0
10:42:45.216226 removexattr("/sys/fs/cgroup/machine.slice", "trusted.delegate") = -1 ENODATA (No data available)
10:42:45.216272 stat("/sys/fs", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
10:42:45.216295 mkdir("/sys/fs/cgroup", 0755) = -1 EEXIST (File exists)
10:42:45.216317 openat(AT_FDCWD, "/sys/fs/cgroup/cgroup.subtree_control", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 23</sys/fs/cgroup/cgroup.subtree_control>
10:42:45.216362 fstat(23</sys/fs/cgroup/cgroup.subtree_control>, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
10:42:45.216498 write(23</sys/fs/cgroup/cgroup.subtree_control>, "-cpu\n", 5) = 5
10:42:45.217000 write(23</sys/fs/cgroup/cgroup.subtree_control>, "-cpuset\n", 8) = -1 EACCES (Permission denied)
10:42:45.219848 write(23</sys/fs/cgroup/cgroup.subtree_control>, "-io\n", 4) = 4
10:42:45.220171 write(23</sys/fs/cgroup/cgroup.subtree_control>, "+memory\n", 8) = 8
10:42:45.222494 write(23</sys/fs/cgroup/cgroup.subtree_control>, "+pids\n", 6) = 6
10:42:45.222546 close(23</sys/fs/cgroup/cgroup.subtree_control>) = 0
10:42:45.222578 removexattr("/sys/fs/cgroup", "trusted.delegate") = -1 ENODATA (No data available)
10:42:45.222618 epoll_wait(4<anon_inode:[eventpoll]>, [{EPOLLIN, {u32=3622445120, u64=94853680209984}}], 63, 0) = 1
10:42:45.222649 read(6<anon_inode:inotify>, "\240\0\0\0\0\200\0\0\0\0\0\0\0\0\0\0\241\0\0\0\0\200\0\0\0\0\0\0\0\0\0\0", 272) = 32  

sh# ausearch -m avc -i
----
type=AVC msg=audit(12/03/2019 10:42:45.218:1989) : avc:  denied  { setsched } for  pid=1 comm=systemd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tclass=process permissive=0

sh# cat /sys/fs/cgroup/cgroup.subtree_control
cpuset memory pids

sh# mount -l | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel)

Do you need more info?

Well this seems strange, Somehow systemd inside of the container is triggering systemd on the host to do a setsced on random processes on the host?

I can see reduced version after reboot

sh# cat /sys/fs/cgroup/cgroup.subtree_control
memory pids

I will need to test on minimal machiine bet steps seems to be


setsebool -P container_manage_cgroup 1

sh-5.0# > /var/log/audit/audit.log 
sh-5.0# getsebool container_manage_cgroup
container_manage_cgroup --> on
sh-5.0# cat /sys/fs/cgroup/cgroup.subtree_control
memory pids
sh-5.0# ausearch -m avc
<no matches>
sh-5.0# podman run --name test-init -t -d registry.access.redhat.com/ubi8/ubi-init:latest
931af7a7abd290bdb63dfb0fe7bd6ae203c4f477d9fd27eb22d39f6927c6a527
sh-5.0# ausearch -m avc
----
time->Tue Dec  3 11:20:04 2019
type=AVC msg=audit(1575390004.895:496): avc:  denied  { setsched } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tclass=process permissive=0
----
time->Tue Dec  3 11:20:04 2019
type=AVC msg=audit(1575390004.912:497): avc:  denied  { setsched } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tclass=process permissive=0
----
time->Tue Dec  3 11:20:04 2019
type=AVC msg=audit(1575390004.920:498): avc:  denied  { setsched } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tclass=process permissive=0
sh-5.0# cat /sys/fs/cgroup/cgroup.subtree_control
cpu io memory pids

(In reply to Daniel Walsh from comment #10)
> Well this seems strange, Somehow systemd inside of the container is
> triggering systemd on the host to do a setsced on random processes on the
> host?

I assume that crun/podman modify /sys/fs/cgroup/cgroup.subtree_control and new sysemd does not like the change.
But systemd folks should have better answer. that might explain why downgrade of systemd "fixed" issues with AVCs

I'm trying to figure out what exactly is happening. It seems that the setsched name is
a red herring, and simply moving processes to a group is what fails:

Dec 03 21:22:34 workstation-uefi audit[1]: AVC avc:  denied  { setsched } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0
                                           tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process permissive=0
Dec 03 21:22:34 workstation-uefi systemd[1]: session-5.scope: Failed to add PIDs to scope's control group: Permission denied
Dec 03 21:22:34 workstation-uefi systemd[1]: session-5.scope: Failed with result 'resources'.
Dec 03 21:22:34 workstation-uefi systemd[1]: Failed to start session-5.scope.

21:22:34.821419 symlink("b22a2d7f4b544193a258f79e682a466a", "/run/systemd/units/.#invocation:session-5.scopede55bc252ac87fcf") = 0
21:22:34.821633 rename("/run/systemd/units/.#invocation:session-5.scopede55bc252ac87fcf", "/run/systemd/units/invocation:session-5.scope") = 0
21:22:34.821757 openat(AT_FDCWD, "/sys/fs/cgroup/user.slice/user-1000.slice/session-5.scope/cgroup.procs", O_WRONLY|O_NOCTTY|O_CLOEXEC) = 37
21:22:34.821874 fcntl(37, F_GETFL)      = 0x8001 (flags O_WRONLY|O_LARGEFILE)
21:22:34.821949 write(37, "1518\n", 5)  = -1 EACCES (Permission denied)
21:22:34.827580 close(37)               = 0
21:22:34.827680 sendmsg(44, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="PRIORITY=4\nSYSLOG_FACILITY=3\nCOD"..., iov_len=186}, {iov_base="MESSAGE=", iov_len=8}, {iov_base="session-5.scope: Failed to add P"..., iov_len=79}, {iov_base="\n", iov_len=1}], msg_iovlen=4, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 274
 > No DWARF information found

After getenforce 0, the same operation succeeds.

> I assume that crun/podman modify /sys/fs/cgroup/cgroup.subtree_control

I *hope* that this is not what is happening. podman's scopes have Delegate=yes,
which means that systemd tries to export all possible controllers to that scope
unit, which means that it must enable those controllers higher up in the tree:
$ systemctl show -p Delegate libpod-ae14bc2bc7688cdc230baa3979f36ca32499fd027b04773a46dca2fd08395c78.scope
Delegate=yes

For example:
$ cat /sys/fs/cgroup/cgroup.subtree_control
memory pids
systemd-run --scope -p Delegate=yes sleep 100 &
[1] 849
Running scope as unit: run-r9d5bbb8e943d42ce84af6ba990867a0f.scope
$ cat /sys/fs/cgroup/cgroup.subtree_control
cpuset cpu io memory pids
This also causes an AVC:
audit[1]: AVC avc:  denied  { setsched } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tclass=process permissive=0

(In reply to Zbigniew Jędrzejewski-Szmek from comment #14)
> $ cat /sys/fs/cgroup/cgroup.subtree_control
> memory pids
> systemd-run --scope -p Delegate=yes sleep 100 &
> [1] 849
> Running scope as unit: run-r9d5bbb8e943d42ce84af6ba990867a0f.scope
> $ cat /sys/fs/cgroup/cgroup.subtree_control
> cpuset cpu io memory pids
> This also causes an AVC:
> audit[1]: AVC avc:  denied  { setsched } for  pid=1 comm="systemd"
> scontext=system_u:system_r:init_t:s0
> tcontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tclass=process permissive=0

That's even simpler reproducer.
And I cannot see it with older systemd (therefore changing component)

sh-5.0# cat /sys/fs/cgroup/cgroup.subtree_control
memory pids
sh-5.0# systemd-run --scope -p Delegate=yes sleep 100 &
[1] 809
sh-5.0# Running scope as unit: run-rc7cde108f8a44bc58263a359320e36b1.scope

sh-5.0# rpm -q systemd
systemd-243.4-1.fc32.x86_64
sh-5.0# cat /sys/fs/cgroup/cgroup.subtree_control
cpu io memory pids
sh-5.0# ausearch -m avc
<no matches>
[1]+  Done                    systemd-run --scope -p Delegate=yes sleep 100
sh-5.0# ausearch -m avc
<no matches>

Oh, I think I understand now! It just doesn't like the cpuset controller support which was
added in systemd v244. Sorry, I should have caught onto this earlier, but I assumed that this
is about some syscall, and not cgroup configuration.

$ systemd-run --scope -p 'Delegate=cpuset' sleep 5 &
$ cat /sys/fs/cgroup/cgroup.subtree_control
cpuset memory pids [with permissive=1]
memory pids        [with permissive=0]

So yeah, please allow this, this is of course intentional.

I now see another AVC for a new feature on EFI systems. I'll open a separate bug for that.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #16)
> Oh, I think I understand now! It just doesn't like the cpuset controller
> support which was
> added in systemd v244. Sorry, I should have caught onto this earlier, but I
> assumed that this
> is about some syscall, and not cgroup configuration.
> 
> $ systemd-run --scope -p 'Delegate=cpuset' sleep 5 &
> $ cat /sys/fs/cgroup/cgroup.subtree_control
> cpuset memory pids [with permissive=1]
> memory pids        [with permissive=0]
> 
> So yeah, please allow this, this is of course intentional.
> 

I assume it should be allowed for all domains and thus added to following rule

sh# sesearch -A -ds -s init_t -dt -t domain -c process
allow init_t domain:process { getattr getpgid noatsecure rlimitinh setrlimit sigchld sigkill signal signull sigstop };

Is that correct assumption ? (sorry for too many needinfos :-)

Yes I agree, we should have this global rule.

+1

*** Bug 1777446 has been marked as a duplicate of this bug. ***

*** Bug 1777157 has been marked as a duplicate of this bug. ***

Is there a plan to fix it in near future?

A PR has been created to address the issue:

https://github.com/fedora-selinux/selinux-policy/pull/313

Awaiting a review.

commit 533b7be0d2b9f6ad895b36cedb2d010ee8be9c03 (HEAD -> rawhide, origin/rawhide)
Author: Zdenek Pytela <zpytela>
Date:   Mon Jan 20 16:29:25 2020 +0100

    Allow init_t set the nice level of all domains BZ(1778088)

Just FTR, I have updated to selinux-policy-3.14.5-24.fc32.noarch and if seems to fix this issue for me.

*** Bug 1787038 has been marked as a duplicate of this bug. ***