GNU bug report logs - #61462
Add support for file capabilities(7)

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>, 61462 <at> debbugs.gnu.org
Subject: [bug#61462] Add support for file capabilities(7)
Date: Tue, 18 Apr 2023 15:14:16 +0200

Hi Vagrant & Tobias,

Sorry for the late reply!

Vagrant Cascadian <vagrant <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.