[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 <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’.
- [bug#61462] Add support for file capabilities(7),
Ludovic Courtès <=