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

[Topi Miettinen]

On 02/11/15 16:32, Lennart Poettering wrote:
> On Wed, 11.02.15 16:24, Topi Miettinen (toiwoton at gmail.com) wrote:
> 
>> On 02/10/15 21:00, Lennart Poettering wrote:
>>> On Sat, 07.02.15 10:40, Topi Miettinen (toiwoton at gmail.com) 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
>