Conversation

Notices

1. Embed this notice
   Lennart Poettering (pid_eins@mastodon.social)'s status on Wednesday, 04-Oct-2023 22:07:58 JST Lennart Poettering

   This whole mess just makes me think we should try harder to kick suid/fcaps out of general purpose Linux distributions. The whole concept is fundamentally backwards, and one of the major weaknesses of traditional UNIX I am sure. The idea behind suid/fcaps of first granting the privileges, inheriting some major, uncontrolled part of the execution environment/resource context/security context and then expecting the binary to securely gate its misuse is just a major mistake: https://www.openwall.com/lists/oss-security/2023/10/03/2

   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Wednesday, 04-Oct-2023 22:07:56 JST 翠星石

     in reply to
     @pid_eins Ah yes, Lennart (m$ employee) tries to fix security forever by replacing simple suid binaries with much more complicated IPC privilege elevation.
   • Embed this notice
     Lennart Poettering (pid_eins@mastodon.social)'s status on Wednesday, 04-Oct-2023 22:07:58 JST Lennart Poettering

     in reply to

     I'd welcome a distribution that'd try hard to address this, and basically run the whole OS with NNP set. Of course, this is not an easy task, people expect their su/sudo to just work, but I am sure these are all addressable, by switching to IPC based privilege elevation for such things.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Saturday, 07-Oct-2023 22:21:30 JST Rich Felker

     in reply to

     • marius
     • James Henstridge

     @jamesh @pid_eins @mariusor Polkit is even worse than suid. It's complex rules represented in code that bypass the standard access controls to grant elevated privilege rather than building a system on top of comprehensible access control primitives.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     James Henstridge (jamesh@aus.social)'s status on Saturday, 07-Oct-2023 22:21:31 JST James Henstridge

     in reply to

     • marius

     @pid_eins @mariusor And polkit still relies on a setuid binary (polkit-agent-helper-1). Of course, that could be fixed by replacing PAM.

   • Embed this notice
     Lennart Poettering (pid_eins@mastodon.social)'s status on Saturday, 07-Oct-2023 22:21:32 JST Lennart Poettering

     in reply to

     • marius

     @mariusor unlikely. And D-Bus has its weaknesses, but security-wise it's a lot more sound than suid/fcaps mess. It has interactive auth via Polkit even. I mean, I'd do it differently sure in my ideal world that only exists in my head, but it's a fundamental improvement over fucking suid/fcaps, hence all power to D-Bus.

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Saturday, 07-Oct-2023 22:21:33 JST marius

     in reply to

     @pid_eins partially related, is there any hope that the in kernel IPC mechanism that was attempted with kdbys/bus-1 will make a resurgence?

     Somehow relying on D-BUS doesn't feel like a great security improvement over suid.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Saturday, 07-Oct-2023 22:22:15 JST Rich Felker

     in reply to

     @pid_eins Make systemd set prctl PR_SET_NO_NEW_PRIVS in pid 1. 😈

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Saturday, 07-Oct-2023 22:23:02 JST Rich Felker

     in reply to

     • marius
     • James Henstridge

     @jamesh @pid_eins @mariusor There is no discoverable documentation for how any of that works, so "human readable" is of marginal value.

     "All decisions are made by code" is a fallacy. There is a fundamental difference in having a finite, very small number of basic rules that lack looping or recursion and that get applied based on pure data, and an entire Turing complete DSL or embedded JS running unbounded amounts of code & evaluating each decision with code that doesn't fit in mental model.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     James Henstridge (jamesh@aus.social)'s status on Saturday, 07-Oct-2023 22:23:03 JST James Henstridge

     in reply to

     • marius
     • Rich Felker

     @dalias @pid_eins @mariusor While I'm not the biggest fan of Polkit's JS rules system, the vast majority of access decisions get made based on the default rules in the action files.

     And at the end of the day, all access decisions are made by code. Having it in human readable text files is not the worst thing in the world.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Saturday, 07-Oct-2023 22:24:01 JST Rich Felker

     in reply to

     • Marcus Müller

     @funkylab @pid_eins It really doesn't. IPC/RPC are bad (high risk) too just in different ways. The right ways to do this are gating access with basic unix permissions needed to access the request socket (or other trigger mechanism) or with ssh (where the problem has already been solved by experts and, in the absence of garbage like PAM, preauth RCE vulns essentially don't happen).

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Marcus Müller (funkylab@mastodon.social)'s status on Saturday, 07-Oct-2023 22:24:02 JST Marcus Müller

     in reply to

     @pid_eins hm. But that basically necessitates solid RPC between an unprivileged client and a privileged system management daemon, which in itself is exactly where we tend to find parsing bugs for decades (like the glibc one triggering this discussion is).
     I'd honestly rather see a kind-of-single-syscall-suid mechanism that only works with a sensible verifiable pledge()-equivalent. Like, think of an xattr that contains ebpf code describing that a privileged open can open exactly one file, and...

   • Embed this notice
     Lennart Poettering (pid_eins@mastodon.social)'s status on Saturday, 07-Oct-2023 22:24:47 JST Lennart Poettering

     in reply to

     • marius
     • Rich Felker
     • James Henstridge

     @dalias @jamesh @mariusor and what's even worse. they are permanent: file ownership/ACL entries are persistently made on some inode, and there's no scheme to clean that up again (unless some – brittle – logic cleans this up manually). Moreover if you have access to an inode you basically have access to it forever, just by keeping an fd open.

     UNIX access control works for simple, relatively static, non-interactive cases, but Polkit is precisely supposed to fill the gap where that's not enough.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Saturday, 07-Oct-2023 22:24:47 JST Rich Felker

     in reply to

     • marius
     • James Henstridge

     @pid_eins @jamesh @mariusor This is largely a gap between ideological purity and practical security. No ordinary user on non shared machine has ever gotten pwned because the system let them keep an open fd to something. Plenty have gotten pwned because polkit handed out root to an unprivileged junk process that asked nicely.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Lennart Poettering (pid_eins@mastodon.social)'s status on Saturday, 07-Oct-2023 22:24:48 JST Lennart Poettering

     in reply to

     • marius
     • Rich Felker
     • James Henstridge

     @dalias @jamesh @mariusor

     UNIX access controls suck though, since they control access to objects, not operations. And they are incompatible with potentially interactive authentication. Both of these things are what Polkit brings to the table: you authenticate actions, and you can allow them to require re-authentication by a user, interactively.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Saturday, 07-Oct-2023 22:24:49 JST Rich Felker

     in reply to

     • marius
     • James Henstridge

     @jamesh @pid_eins @mariusor With basic unix access controls, there is also testability. You know the extremely limited set of variables that the result of permission checks can depend on, and can test what happens with those. Polkit on the other hand has a nearly unbounded set of possible inputs to make its decisions based on, making the security of a configuration effectively untestable.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Saturday, 07-Oct-2023 22:24:50 JST Rich Felker

     in reply to

     • marius
     • James Henstridge

     @jamesh @pid_eins @mariusor The problem with it being JS (and with none of this being documented or discoverable) isn't a matter of whether the JS code that's present is doing complex stuff that needs Turing completeness.

     It's that it's not comprehensible to the user responsible for managing their own security. There are no limitations on the mechanisms they can use as a shortcut for reasoning (like they could with unix permissions) so they need to read/memorize/understand all that code!

   • Embed this notice
     James Henstridge (jamesh@aus.social)'s status on Saturday, 07-Oct-2023 22:24:51 JST James Henstridge

     in reply to

     • marius
     • Rich Felker

     @dalias @pid_eins @mariusor I work on a distribution that is only upgrading to a JS-capable polkit in this month's release: more than a decade after upstream made the change.

     In the grand scheme of things, I don't think it is particularly important. We're talking about a couple of hundred lines of JS that doesn't make use of loops and is very easy to reason about. A more restricted language could achieve the same thing, but it's not something I think is worth fighting about.