On 02/11/15 16:32, Lennart Poettering wrote: > On Wed, 11.02.15 16:24, Topi Miettinen ([email protected]) wrote: > >> On 02/10/15 21:00, Lennart Poettering wrote: >>> On Sat, 07.02.15 10:40, Topi Miettinen ([email protected]) wrote: >>> >>>> No setuid programs are expected to be executed, so add >>>> SecureBits=no-setuid-fixup no-setuid-fixup-locked >>>> to unit files. >>> >>> So, hmm, after reading the man page again: what's the rationale for >>> precisely these bits? >>> >>> I mean no-setuid-fixup seems to be something that applies to setuid(), >>> setresuid() calls and suchlike, which seems pretty uninteresting. Much >>> more interesting is SECBIT_NOROOT, which disables suid binary >>> handling... >> >> Yes, noroot noroot-locked was actually my intention, sorry. I'll update >> the patch. >> >> Maybe all of "noroot noroot-locked no-setuid-fixup >> no-setuid-fixup-locked" would be OK, but that probably needs another >> look at the programs if they switch UIDs. > > I'd be careful with more than noroot, since the other flags alter > bbehaviour across setuid() and similar calls, and much of our code > makes assumptions that will likely not hold if you set those bits...
Going back to no-setuid-fixup no-setuid-fixup-locked: First, I looked at the kernel code if it matches the description on the manual page capabilities(7) to prevent more embarrassment. In this case it does, NO_SETUID_FIXUP prevents capability changes when the task calls set[res]*uid(). Then I looked at all use cases of set[res]*uid() in systemd. They are called directly by run and nspawn. Then they are used when connecting to journal and setting up PAM in exec_spawn() as well as in namespace_enter(). These in turn are used by sd-bus init which is used by unit setup, so pretty much everything is affected. The good thing is that none of the daemons except machined use these directly. drop_privileges() uses set[res]*uid() and it is called from resolved, coredump, networkd, timesyncd and bus-proxyd. So avoiding those, at least the following could be candidates: systemd-hostnamed.service systemd-importd.service systemd-journal-gatewayd.service systemd-journal-remote.service systemd-journal-upload.service systemd-journald.service systemd-localed.service systemd-logind.service systemd-timedated.service It could still be possible that an external library could detect that uid==0 and then switch uids to do things at lower privilege. This would work, but the capabilities would not be dropped. There's of course the question whether no-setuid-fixup no-setuid-fixup-locked is useful. For daemons runnig as root, it would not help anything (or could even make things worse e.g. in the library case). But when the daemon runs as a different user, the flags could make the life of attacker a tiny bit more difficult. This leaves only: systemd-journal-gatewayd.service systemd-journal-remote.service systemd-journal-upload.service I can make a patch for those if you agree, or the original patch can be applied selectively. Maybe more daemons should run as unprivileged user. -Topi > > Lennart > _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
