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

["Ludovic Courtès" <ludo@gnu.org>]

Hi Vagrant & Tobias,

Sorry for the late reply!

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.

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

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

[...]

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

>> I’m very much sold to the principle of least authority, but I feel like
>> POSIX capabilities (not to be confused with “actual” capabilities) are a
>> bit of a hack.
>
> And setuid/setgid is not a hack? It seems like essentially the same
> thing, just with no granularity...

That’s right!

> There are some things that are just not possible without capabilities,
> and setuid/setgid is a dangerous hammer that should be used very
> sparingly, if at all, and capabilities are no *worse* that
> setuid/setgid, allowing a finer grained set of problems :)
>
> The need for this functionality has come up more than a few times:
>
>   https://issues.guix.gnu.org/27415
>   https://issues.guix.gnu.org/39136
>   https://issues.guix.gnu.org/55683

Right; thanks for digging the references.

I wouldn’t want to block this change.  Tobias, if you’re around, let’s
look more closely how we can address Hurd suppot and backward
compatibility.

Thanks,
Ludo’.