[systemd-devel] [PATCH] units: add SecureBits

[Lennart Poettering]

On Sat, 14.02.15 12:32, Topi Miettinen (toiwoton at gmail.com) 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