Hello,
po 31. 1. 2022 v 18:13 odesílatel Steve Grubb <sgrubb(a)redhat.com> napsal:
On Monday, January 31, 2022 5:36:24 AM EST Lennart Poettering wrote:
> On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
>
> I vehemently disagree. The thing with setuid/setgid is that the
> invoked privileged process inherits a lot of implicit state and
> context that people aren't really aware of or fully
> understand. i.e. it's not just env vars and argv[], it's cgroup
> memberships, audit fields, security contexts,
For security reasons, we count on these last two. We count on a property
called non-repudiation.
I imagine an IPC with capability-like objects (in the microkernel sense,
not in the “POSIX capability” sense) could easily enough, on use, log both
who the capability was originally issued to, and who ultimately used it (or
even every single transition across an user account / login ID). In theory.
We also count on a user with a specific selinux user
cannot escape that assigment.
OTOH the SELinux kernel-objects-only (basically files-only) confinement is
inherently limited to only the concepts the kernel understands. So there’s
a “write to /etc/passwd” capability but it isn’t possible to separately
give some users “add a user to /etc/passwd” and “change one’s own real name
in /etc/passwd” features, as far as the kernel is concerned. So the set-uid
executable that is used to write to /etc/passwd is still a part of the
trusted base, in the sense that it could be exploited not just to
immediately write unexpected data to /etc/passwd, but possibly because an
exploit payload written *elsewhere* (/etc/nsswitch.conf? /lib64/*?) could
be used to exploit the set-uid executable and cause it to misattribute a
kernel-visible /etc/passwd write to a “victim” user who just happened to be
exploited.
An IPC-based system could provide *much better* auditability and control,
because it could be granular at the level of individual operations — sure,
at a non-trivial cost; a lot of the IPC servers would end up a part of the
(semi-) trusted base, at least to the extent that they need to properly
audit use of the operations they provide. But, as described above, they are
already basically trusted to this extent today.
But doesn't satisfy our security requirements. If the kernel dbus
project
had
been successful, then Linux would have had a rock solid basis to allow
impersonation which would satisfy the security requirements and allow the
desktop actually go through a common criteria certification if any one
ever
wanted to do that. But as it stands, anything created by IPC is missing
the
necessary security context.
I mean, yes. I read that as not a reason to stick with set-uid, but as a
reason to make that a priority, and drive the investment and the cultural
change; otherwise Linux security is just going to keep falling behind. OTOH
with the consolehelper history and a lot of similar examples, I don’t know
how to do any of that (make it a priority, drive the investment, drive the
cultural change).
Also, it's impossible to reason about what's allowed and what's not because
the policy is free-form javascript rather than assignments that can
be
checked by any configuration scanners.
Polkit’s JavaScript is certainly a mistake, but 1) that’s unrelated to the
general use of IPC, 2) for Common Criteria it would be trivial enough to
say “the only Polkit Configuration is exactly this blob that invokes
polkit-pkla-compat”, and enforce it with OpenSCAP and kernel’s file system
audit rules.
And access decisions do not go through
the audit system.
For polkit, that would be… a 20-line patch? Sure, the invoking user’s
configuration can be trusted only to the extent a D-Bus server provides it
correctly to Polkit, making the D-Bus servers a part of the trusted
codebase. Still, that would be pretty valuable at least until the first
successful exploit.
Mirek