On Monday, January 31, 2022 5:36:24 AM EST Lennart Poettering wrote:
> On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam@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