[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 07 Nov 2022 18:09:01 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: libc-coord@...ts.openwall.com
Subject: Re: Per-thread file system attributes
* Rich Felker:
>> > The "filesystem uid/gid" extension Linux has (setfsuid/setfsgid) is
>> > already per-thread by convention due glibc choosing (and musl & uclibc
>> > doing likewise) not to make it process-global with a broadcast. It's a
>> > lot more suitable than overloading the POSIX real/effective/saved
>> > uid/gid for this purpose, as the latter are intended as security
>> > boundaries and the "fs" ones are just intended for implementing file
>> > servers.
>>
>> setfsuid/setfsgid have been deprecated since the switch to different
>> setresuid semantics in the kernel. And you could never use them to
>> handle supplementary groups, I think.
>
> Do you have a reference for that change? I was unaware of it. This
> seems rather unfortunate.
It's in the manual page for kill:
| For a process to have permission to send a signal, it must either
| be privileged (under Linux: have the CAP_KILL capability in the
| user namespace of the target process), or the real or effective
| user ID of the sending process must equal the real or saved set-
| user-ID of the target process. In the case of SIGCONT, it
[NB: not the effective user ID of the target]
| suffices when the sending and receiving processes belong to the
| same session. (Historically, the rules were different; see
| NOTES.)
[…]
| Linux notes
|
| Across different kernel versions, Linux has enforced different rules
| for the permissions required for an unprivileged process to send a sig‐
| nal to another process. In kernels 1.0 to 1.2.2, a signal could be
| sent if the effective user ID of the sender matched effective user ID
| of the target, or the real user ID of the sender matched the real user
| ID of the target. From kernel 1.2.3 until 1.3.77, a signal could be
| sent if the effective user ID of the sender matched either the real or
| effective user ID of the target. The current rules, which conform to
| POSIX.1, were adopted in kernel 1.3.78.
<https://man7.org/linux/man-pages/man2/kill.2.html>
In practice, I think FSUID confers pretty much the same privileges as
EUID, so I don't think it's a regression in security hardening
capabilities or something like that.
And of course, there's also the supplementary groups issue, which was
never covered under the FSUID/FSGID approach.
Thanks,
Florian
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
