Container issues in enforcing mode on Debian 12 about refpolicy HOT 13 CLOSED

from refpolicy.

Apologies, it seems to be working now ; partially. After spinning up a new Debian VPS 4 more times, the error proved irreproducible and podman seems to be functioning now, both in rootful and rootless modes.

Conmon however remains: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1093 ? 00:00:00 conmon

Looking in container.fc, container.if and container.te reveals little or no mention of conmon - although I'll be the first to admit that I am a total noob when it comes to writing SELinux policies..

Is confining conmon still on a ToDo list perhaps? Or has it been altered and will it need to be backported to Debian 12...?

from refpolicy.

@0xC0ncord - Ah I see, thank you very much for the explanation, that makes things a lot more clear. I shall spin up a new VPS and try it out - and report back asap.

from refpolicy.

Sorry for the bother again:

I've hit a bit of a wall in testing..

Created a system account and tried to get systemd (systemctl --user) working, permission is denied to create /run/user/999. Linger has been enabled and in SELinux permissive mode it works fine, in enforcing mode however:

testing (systemd)[800]: pam_selinux(systemd-user:session): Unable to get valid context for testing
testing (systemd)[800]: pam_selinux(systemd-user:session): conversation failed
testing (systemd)[800]: pam_unix(systemd-user:session): session opened for user testing(uid=999) by (uid=0)
testing (systemd)[800]: PAM failed: Cannot make/remove an entry for the specified session
testing (systemd)[800]: [email protected]: Failed to set up PAM session: Operation not permitted
testing (systemd)[800]: [email protected]: Failed at step PAM spawning /lib/systemd/systemd: Operation not permitted

Along with:

audit[694]: AVC avc: denied { read write } for pid=694 comm="modprobe" path="socket:[14151]" dev="sockfs" ino=14151 scontext=system_u:system_r:kmod_t:s0 tcontext=system_u:system_r:podman_t:s0 tclass=unix_stream_socket permissive=0
audit[693]: AVC avc: denied { write } for pid=693 comm="resolvconf" name="run-lock" dev="tmpfs" ino=454 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file permissive=0 ifup[693]: /sbin/resolvconf: 100: cannot create /run/resolvconf/run-lock: Permission denied
audit[697]: AVC avc: denied { search } for pid=697 comm="dhclient-script" name="netif" dev="tmpfs" ino=350 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:systemd_networkd_runtime_t:s0 tclass=dir permissive=0
audit[697]: AVC avc: denied { search } for pid=697 comm="sed" name="netif" dev="tmpfs" ino=350 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:systemd_networkd_runtime_t:s0 tclass=dir permissive=0

(Posted the 2nd half for sake of completeness, I doubt that has anything to do with the systemd user issue).

I have tried usermod -Z system_u exampleuser as well as usermod -Z user_u exampleuser and it does show up in semanage login -l but permission is denied regardless.

I noticed that there is a systemd module loaded in Almalinux. I looked around but it seems that in refpolicy it is loaded as systemd = base, so I assumed that it doesn't need to be added as a module.

Edit 1:

I noticed that Almalinux has /etc/selinux/default/contexts/systemd_contexts` containing:

runtime=system_u:object_r:systemd_runtime_unit_file_t:s0

There is no such file in Debian 12; it instead has /etc/selinux/default/contexts/initrc_contexts and /etc/selinux/mls/contexts/initrc_contexts (respectively) containing:

system_u:system_r:initrc_t:s0

system_u:system_r:initrc_t:s0-s15:c0.c1023

Could this be the culprit?

from refpolicy.

Would you be able to post the output of the audit log with semodule -DB (disable dontaudit rules) in effect? The error Operation not permitted seems indicative of SELinux denying a required capability in this case.

from refpolicy.

I've just run into this same issue on Debian Bookworm 12.1, and followed the same steps as the OP:

cd /usr/src/
apt-get source refpolicy
cd refpolicy-2.20221101/
cat debian/modules.conf.default
echo "container = module" >> debian/modules.conf.default
./debian/rules build-default-policy
setenforce 0
semodule -i debian/build-default/container.pp

Oddly, starting up a container "works" although actually executing the code in the container doesn't.

I'm running the Transmission docker image in podman from a systemd unit like this (note the UID 0 inside the container, but the unprivileged user _twriter as the user that's actually running podman):

[Install]
WantedBy=multi-user.target

[Unit]
Description=Transmission service. (4.0.3)
Wants=network-online.target
After=network-online.target

[Service]
Slice=services-transmission01.slice
Type=exec
User=_twriter
Group=_twriter
Restart=on-failure
RestartSec=10s
TimeoutStopSec=70
TimeoutStartSec=300

ExecStart=/usr/bin/podman \
  run \
  --name transmission01 \
  --rm \
  --replace \
  --env 'PASS=REDACTED' \
  --env 'PGID=0' \
  --env 'PUID=0' \
  --env 'USER=tv' \
  --cpus 1.0 \
  --memory 2000000000 \
  --volume '/data/transmission01/downloads:/downloads:rw,z' \
  --volume '/data/transmission01/etc:/config:rw,z' \
  --network='slirp4netns:outbound_addr6=REDACTED,outbound_addr=REDACTED' \
  --publish 'REDACTED:9091:9091/tcp' \
  registry.REDACTED:5000/transmission:4.0.3@sha256:6751678a4219af7787ae26a25babcf41a0f613e8b4fed5ddaacf95c34acf04fa


ExecStop=/usr/bin/podman \
  stop \
  --ignore \
  --time 60 \
  transmission01

ExecStopPost=/usr/bin/podman \
  rm \
  --ignore \
  --force \
  --time 60 \
  transmission01

The container gets right to the point of executing the /init process inside the container and then fails:

Jul 26 21:34:06 media01 conmon[9839]: conmon 2aee9d103f755c5233e7 <ndebug>: Accepted console connection 14
Jul 26 21:34:06 media01 podman[9794]: time="2023-07-26T21:34:06+01:00" level=debug msg="Started container 2aee9d103f755c5233e7bfd25e04c8c6dc38fb5f02caf128a87f9d3b3fcdf3c4"
Jul 26 21:34:06 media01 podman[9794]: time="2023-07-26T21:34:06+01:00" level=debug msg="Notify sent successfully"
Jul 26 21:34:06 media01 transmission01[9839]: exec container process `/init`: Permission denied

Looking in the audit log, I see:

type=AVC msg=audit(1690403657.265:249): avc:  denied  { transition } for  pid=10157 comm="3" path="/init" dev="nvme0n1p3" ino=537170087 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:container_t:s0:c564,c860 tclass=process permissive=0

I'm not clear on whether this is an expected failure or not.

from refpolicy.

from refpolicy.

# ls -alFZ /usr/bin/podman 
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 32969312 May 18 09:44 /usr/bin/podman*

from refpolicy.

I forgot to check in on this issue a while back, sorry.

# ls -alFZ /usr/bin/podman 
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 32969312 May 18 09:44 /usr/bin/podman*

That seems to be the problem. podman should be labeled podman_exec_t.

from refpolicy.

This issue has not had any recent activity. It will be closed in 7 days if it makes no further progress.

from refpolicy.

No problem; I managed to miss your response. 😆

I should be able to try this out in a few days.

from refpolicy.

This issue has not had any recent activity. It will be closed in 7 days if it makes no further progress.

from refpolicy.

Closing stale PR.

from refpolicy.