Replies: 2 comments 5 replies
-
|
Small update: it seems that the fault doesn't lie on devsec's role but on the systemd service unit. Right now the definition for Caddy is as follows: [Unit]
Description=Caddy for SZN
[Container]
Image=docker.io/library/caddy:2.7-alpine
Network=szn-public.network
Volume=/home/kosuzu/.local/share/szn/caddy/Caddyfile:/etc/caddy/Caddyfile:ro,Z
Volume=/home/kosuzu/.local/share/szn/caddy/data:/data:Z
Volume=/home/kosuzu/.local/share/szn/caddy/config:/config:Z
PublishPort=8080:80
PublishPort=4430:443
PublishPort=4430:443/udp
AutoUpdate=registry
[Service]
Restart=on-failure
ProtectProc=invisible
# ANY of these settings make podman crash on newuidmap
#ProtectHome=yes
#PrivateMounts=yes
#PrivateTmp=yes
#ProtectKernelTunables=yes
#LockPersonality=yes
#ProtectSystem=strict
#ReadWritePaths=/home/kosuzu/.local/share/szn/caddy/data /home/kosuzu/.local/share/szn/caddy/config
#ReadOnlyPaths=/home/kosuzu/.local/share/szn/caddy/Caddyfile /home/kosuzu/.config/containers/storage.conf
#SystemCallArchitectures=native
#MemoryDenyWriteExecute=yes
[Install]
WantedBy=multi-user.target default.target
; vim: ft=systemdMaybe something changed with the systemd version introduced in Fedora 39? |
Beta Was this translation helpful? Give feedback.
-
|
Figured it out: the problem stems from the fact that apply the various ProtectProc=invisible
# OR "ProtectProc=noaccess", depending on the service
SystemCallArchitectures=native
MemoryDenyWriteExecute=trueNote that, as documented in RedHat's article, [Unit]
Description=podman-usernamespace.service
[Service]
Type=oneshot
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman unshare /bin/true
RemainAfterExit=yesThen add Probably on older versions of systemd either the |
Beta Was this translation helpful? Give feedback.
-
|
Did you ever find anything? I'm trying to restrict a docker CI builder, but even setting |
Beta Was this translation helpful? Give feedback.
-
|
Nope. The reason for that is that podman is basically already doing what systemd's |
Beta Was this translation helpful? Give feedback.
-
|
Not using podman, but docker rootless and I don't think I can lock paths that docker cannot write any other way. The problem is that of course docker already protects against all of that from inside the container, but I do not trust the source that creates the container / fear code escaping the container. Especially the problem is that I have a docker running inside a privileged (has to be privileged) container and anyone who can start a CI job basically can create a privileged(or map stuff that they shouldn't) container inside the privileged container an escape that way onto the host at which point I can limit them anymore without systemd, which is why I) basically want everything to be readonly except docker's storage path. I don't fear the extraction of information but the injection of something malicious which is persistent. |
Beta Was this translation helpful? Give feedback.
-
|
I think that the best course of action is to ask systemd's maintainers to provide a way to specify additional capabilities for the initial call to One workaround is to use a container runner that you run inside another container (like in this forgejo-runner discussion); so basically doing, e.g., podman in podman. Another workaround is to create a system-level unit and assign an |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I'll maybe try the system unit. Container inside containers doesn't work though, as the outer container has to be privileged, effectively voiding all security restrictions. |
Beta Was this translation helpful? Give feedback.
-
Issue Description
I am running some rootless containers using quadlet under an user
kosuzu(uid=1001).After executing devsec's os_hardening role and updating to Fedora 39, they won't start under systemd anymore with the following error:
Using
podmanfrom the shell works.The shell is setup after SSH by running
sudo -u kosuzu -sand thenexport XDG_RUNTIME_DIR=/run/user/$(id -u).Neither running
podman system migratenorpodman system resetinside the shell setup as above, or viasystemd-run, resolve the issue:I am not entirely sure it is a fault of the role, since I also updated to Fedora 39 in the meantime. The best guess I have right now is that, since the shell environment works fine, I have a broken configuration and/or a permission issue related to systemd's environment.
Thank you in advance for your help.
Steps to reproduce the issue
Steps to reproduce the issue
Create some quadlet definitions:
~/.config/containers/szn-caddy.container
~/.config/containers/szn-homeassistant.container
(Maybe?) Apply devsec.hardening.os_hardening role as such:
Reboot and start the containers:
Describe the results you received
From
journalctl:szn-caddy.service
szn-homeassistant.service
Describe the results you expected
Before running the role and updating to F39 the services ran fine, including when running with the hardening options shown in Caddy's container definition.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
No
Additional environment details
newuidmapandnewgidmaphave the correct capabilities:They don't have suid bit set.
Here follows the contents of
/etc/subuidand/etc/subgid:The mounts inside
/runhavenosuidset, but this behaviour is the same as my desktop computer, which has not run the os_hardening role and is also on F39.Removing
nosuidfromfstaband re-mounting does not resolve the issue.SELinux is set to enforcing with
targetedpolicy, but setting it to permissive does not change anything.Additional information
No response
Beta Was this translation helpful? Give feedback.
All reactions