On 01/27/15 22:19, Lennart Poettering wrote: > On Tue, 27.01.15 21:58, Topi Miettinen (toiwo...@gmail.com) wrote: >>> Well, the way I read the paragraph above if we set PR_SET_NO_NEW_PRIVS >>> after forking, but before execing systemd-timesyncd, and that binary >>> has an selinux label on it, that the selinux label would be ignore, >>> and things would continue to run with the same label as we forked >>> off. This pretty much renders SELinux usesless, since all services >>> where we set the bit for would then run as "init_t"... and that's >>> something we really shouldn't do. >> >> seccomp_filter.txt on the other hand says that >> "Prior to use, the task must call prctl(PR_SET_NO_NEW_PRIVS, 1) or >> run with CAP_SYS_ADMIN privileges in its namespace. If these are not >> true, -EACCES will be returned. This requirement ensures that filter >> programs cannot be applied to child processes with greater privileges >> than the task that installed them." >> >> Does this mean that SELinux and seccomp are mutually exclusive? Awful >> design if so. > > Well, no it doesn't mean that. If systemd sets up a seccomp filter it > has CAP_SYS_ADMIN, hence all is good. And it can leave > PR_SET_NO_NEW_PRIVS off, and thus not break selinux.
So in conclusion, only the SecureBits part would be interesting. Looking at the unit files, which of them expect to run setuid helpers? I looked at the unit files and briefly at the corresponding programs (also to get to know them better), so I offer my guesses below: units/console-getty.service.m4.in getty launches user shell, so no. units/console-shell.service.m4.in sulogin launches root shell, so no. units/container-ge...@.service.m4.in getty launches user shell, so no. units/debug-shell.service.in sushell launches root shell, so no. units/emergency.service.in sulogin launches root shell, so no. units/getty@.service.m4 getty launches user shell, so no. units/halt-local.service.in Local scripts could launch anything, so no. units/initrd-cleanup.service.in Only calls systemctl, so yes. units/initrd-parse-etc.service.in Only calls systemctl, so yes. units/initrd-switch-root.service.in Only calls systemctl, so yes. units/initrd-udevadm-cleanup-db.service.in Only calls udevadm, so yes. units/kmod-static-nodes.service.in kmod is not part of systemd, but I wouldn't expect it to use setuid helpers, so yes? units/ldconfig.service ldconfig is not part of systemd, but I wouldn't expect it to use setuid helpers, so yes? units/quotaon.service.in quotaon is not part of systemd, but I wouldn't expect it to use setuid helpers, so yes? units/rc-local.service.in Local scripts could launch anything, so no. units/rescue.service.in sulogin launches root shell, so no. units/serial-getty@.service.m4 getty launches user shell, so no. units/systemd-ask-password-console.service.in Only calls systemd-ask-password-agent, so yes. units/systemd-ask-password-wall.service.in Only calls systemd-ask-password-agent, so yes. units/systemd-backli...@.service.in Only calls systemd-backlight, so yes. units/systemd-binfmt.service.in Only calls systemd-binfmt, so yes. units/systemd-bootchart.service.in Only calls systemd-bootchart, so yes. units/systemd-bus-proxyd.service.m4.in Only calls systemd-bus-proxyd, so yes. units/systemd-firstboot.service.in Only calls systemd-firstboot. It doesn't seem to use pam_unix (which could launch setuid helper unix_chkpwd) for checking passwords, but internal implementation, so yes. units/systemd-fsck-root.service.in Only calls systemd-fsck, so yes. units/systemd-f...@.service.in Only calls systemd-fsck, so yes. units/systemd-halt.service.in Only calls systemctl, so yes. units/systemd-hibernate-res...@.service.in Only calls systemd-hibernate-resume, so yes. units/systemd-hibernate.service.in Only calls systemd-sleep, so yes. units/systemd-hostnamed.service.in Only calls systemd-hostnamed, so yes. units/systemd-hwdb-update.service.in Only calls systemd-hwdb, so yes. units/systemd-hybrid-sleep.service.in Only calls systemd-sleep, so yes. units/systemd-importd.service.in Calls systemd-importd, which in turn executes several helpers, especially gpg which could be setuid to lock memory, so no. units/systemd-initctl.service.in Only calls systemd-initctl, so yes. units/systemd-journal-catalog-update.service.in Only calls systemd-journalctl, so yes. units/systemd-journald.service.in Only calls systemd-journald, so yes. units/systemd-journal-flush.service.in Only calls systemd-journalctl, so yes. units/systemd-journal-gatewayd.service.in Only calls systemd-journal-gatewayd, so yes. units/systemd-journal-remote.service.in Calls systemd-journal-remote, which in turn uses microhttpd that uses several external libs, maybe no? units/systemd-journal-upload.service.in Only calls systemd-journal-upload (uses curl), so yes. units/systemd-kexec.service.in Only calls systemctl, so yes. units/systemd-localed.service.in Only calls systemd-localed, so yes. units/systemd-logind.service.in Calls systemd-logind, which can start user services, so no? units/systemd-machined.service.in Launches machine instances, but that is done via dbus, so yes? units/systemd-machine-id-commit.service.in Only calls systemd-machine-id-commit, so yes. units/systemd-modules-load.service.in Calls systemd-modules-load which uses libkmod, so yes? units/systemd-networkd.service.in Only calls systemd-networkd, so yes? Setting the bits could be done in drop_privileges() if this is OK for other users too (bus-proxyd, resolved, journald, and timesyncd). units/systemd-networkd-wait-online.service.in Only calls systemd-networkd-wait-online, so yes. units/systemd-nsp...@.service.in Can launch anything, so no. units/systemd-poweroff.service.in Only calls systemctl, so yes. units/systemd-quotacheck.service.in quotacheck is not part of systemd, but I wouldn't expect it to use setuid helpers, so yes? units/systemd-random-seed.service.in Only calls systemd-random-seed, so yes. units/systemd-reboot.service.in Only calls systemctl, so yes. units/systemd-remount-fs.service.in Launches /bin/mount which usually is setuid. As it is executed as root with full capabilities, it should be OK. units/systemd-resolved.service.in Only calls systemd-resolved, so yes. units/systemd-rfk...@.service.in Only calls systemd-rfkill, so yes. units/systemd-shutdownd.service.in Only calls systemctl, so yes. units/systemd-suspend.service.in Only calls systemd-sleep, so yes. units/systemd-sysctl.service.in Only calls systemd-sysctl, so yes. units/systemd-sysusers.service.in Calls systemd-sysusers. NSS helpers could in theory be setuid, so no. units/systemd-timedated.service.in Only calls systemd-timedated, so yes. units/systemd-timesyncd.service.in Only calls systemd-timesyncd, so yes. units/systemd-tmpfiles-clean.service.in Only calls systemd-tmpfiles, so yes. units/systemd-tmpfiles-setup-dev.service.in Only calls systemd-tmpfiles, so yes. units/systemd-tmpfiles-setup.service.in Only calls systemd-tmpfiles, so yes. units/systemd-udevd.service.in udevd helpers can be anything, so no. units/systemd-udev-settle.service.in Only calls udevadm, so yes. units/systemd-udev-trigger.service.in Only calls udevadm, so yes. units/systemd-update-done.service.in systemd-update-done uses SELinux libs which could do anything, so no? units/systemd-update-utmp-runlevel.service.in systemd-update-utmp uses audit libs which could do anything, so no? units/systemd-update-utmp.service.in systemd-update-utmp uses audit libs which could do anything, so no? units/systemd-user-sessions.service.in Only calls systemd-user-sessions, so yes. units/systemd-vconsole-setup.service.in systemd-vconsole-setup uses loadkeys and setfont which are not part of systemd, but they are unlikely to be setuid, so yes. units/u...@.service.m4.in Calls systemd --user, which will start user specified units which can be setuid, so no. -Topi _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel