[systemd-devel] [PATCH] timesyncd: tighten unit file

[Topi Miettinen]

On 01/27/15 22:19, Lennart Poettering wrote:
> On Tue, 27.01.15 21:58, Topi Miettinen (toiwoton at 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-getty at .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 at .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 at .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-backlight at .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-fsck at .service.in

Only calls systemd-fsck, so yes.

units/systemd-halt.service.in

Only calls systemctl, so yes.

units/systemd-hibernate-resume at .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-nspawn at .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-rfkill at .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/user at .service.m4.in

Calls systemd --user, which will start user specified units which can be
setuid, so no.

-Topi