[bug#61462] Add support for file capabilities(7)

[Vagrant Cascadian]

On 2023-04-18, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> skribis:
>
>>>> I'm quite opinionated about the setuid-programs unification: there
>>>> should not be multiple confusing and masking layers of privilege, and
>>>> it should be possible to setgid a capable executable.
>>>
>>> So you mean that ‘privileged-programs’ should entirely replace
>>> ‘setuid-programs’, right?
>>>
>>> I’m a bit unsure about using file capabilities:
>>>
>>>   1. File capabilities are persistent and less visible than setuid bits
>>>      (you won’t see them with “ls -l”), so easily overlooked.  Could
>>>      there be a risk of lingering file capabilities when reconfiguring a
>>>      system?
>>
>> Does reconfigure leave old setuid binaries laying around in
>> /run/setuid-programs currently?
>
> No: ‘activate-setuid-programs’ first deletes /run/setuid-programs/*,
> then populates it.

Good!

>> Seems like with setuid/setgid and the proposed priviledged binaries, the
>> setuid/setgid bits and capabilties should be explicitly set on any
>> defined binaries, and any that are left over in the /run/*-programs
>> directories should be... forcibly removed! Otherwise your current system
>> is vulnerable to previous potentially bad choices indefinitely...
>
> Right, so in that sense it’s no different from setuid binaries, other
> than the fact that “ls -l” won’t show it.

That aspect seems fixable with documentation in the simplest case of how
to show that /run/*-programs contains the correct permissions, e.g a
brief mention of "getcap" to show the capabilities.

The most fancy case I quickly think of might be "guix system
list-privledged-programs" or some such that would display all the
various privledges (setuid, setgid, capabilities, etc.) on each of the
binaries in /run/*-programs? But probably overkill...


>>>   2. How ’bout portability to different file systems and to GNU/Hurd?
>>
>> Currently I *think* /run/setuid-programs is tmpfs
>
> It’s not by default.

Huh, could have sworn on all my guix systems that /run was on tmpfs by
default, and I did not knowingly do anything special to change that...


>> In all seriousness though, while I appreciate thinking about broad
>> compatibility across different types of systems, I am a bit nervous
>> about an approach that would require features to behave compatibly
>> across all systems...
>
> I guess All I’m saying is that we should keep this in mind.
>
> Perhaps the hypothetical ‘activate-privileged-programs’ procedure would
> fall back to setuid-root on GNU/Hurd or do some other Hurd-specific
> thing.  We don’t need to go too far, but we do need to give it some
> thought IMO.

If it cannot properly set the capabilities, then it should not assume
setuid-root is an ok fallback; it should instead most definitely just
fail!

At least the case I am most familiar with, lcsync, it really should not
run as setuid-root, as that effectively allows anyone to modify or copy
any file as root. Although, likely Hurd limits the impacts of setuid
root in ways I do not understand?

Even then, I still think if you ask for something in your guix system
configuration, and it cannot deliver what you asked for, it should not
give you something else as an approximation of what you wanted. Maybe
that is a strict interpretation of an ideal, and reality is much harder
than that. :)


live well,
  vagrant

signature.asc
Description: PGP signature