On Sat, 14.02.15 12:32, Topi Miettinen ([email protected]) wrote: Sorry for the late response, still going through piles of mail.
> >>>> 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(). Any kind of changes? Both dropping and acquiring them? I mean, I think we should actually allow dropping them unless we explicitly say no during one transition. I have the suspicion that the SECBIT_NOROOT thing is the only really interesting one... > 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. I think all long-running ones that reasonably can already do. I mean, things like logind simple need too many caps, it's really not worth trying to make them run under a different uid, because they have so much privs otherwise... Which daemons do you precisely have in mind? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
