[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ludovic Courtès
Subject: [bug#61462] Add support for file capabilities(7)
Date: Tue, 18 Apr 2023 15:14:16 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi Vagrant & Tobias,

Sorry for the late reply!

Vagrant Cascadian <> 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:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]