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

[Topi Miettinen]

On 04/24/15 14:52, Lennart Poettering wrote:
> 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.

Both ways IIRC.

> I have the suspicion that the SECBIT_NOROOT thing is the only
> really interesting one...

I think they are all pretty much useless. SECURE_NOROOT could be
improved by splitting it to two bits, one controlling setuid execution
and the other to control whether capabilities are dropped at exec(). At
least the manual page should be in synch with reality.

Perhaps MAC systems would be better to enforce capability limits
throughout the whole system. Unfortunately my favourite, TOMOYO, does
not manage capabilities.

>> 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?

Nothing in particular. Privilege separation could help even in cases
where some caps need to be retained.

-Topi

> 
> Lennart
>