Sudo and its alternatives [LWN.net]

Sudo and its alternatives

Posted Feb 21, 2024 20:08 UTC (Wed) by bluca (subscriber, #118303) [Link] (12 responses)

Yes - or in other words, a bog-standard run-of-the-mill Linux system as you'll find on the default install of the vast, vast majority of Linux distros.

Sudo and its alternatives

Posted Feb 21, 2024 21:39 UTC (Wed) by marcus0x62 (guest, #168201) [Link] (11 responses)

There is a fundamental difference between having those things on a system, and using them in an elaborate scheme (“attack surface”) to arbitrate privileged execution.

Sudo and its alternatives

Posted Feb 21, 2024 22:01 UTC (Wed) by bluca (subscriber, #118303) [Link] (10 responses)

Not really? All those components are already there and widely used together as part of day-to-day system usage. Even the new uid0 is pretty much bells and whistles (and pam integration) on top of systemd-run, which has existed since forever. It was basically an extra ~200 lines of code, pretty much the same size as its manpage, mostly about new command line parameters parsing.

Sudo and its alternatives

Posted Feb 21, 2024 22:56 UTC (Wed) by marcus0x62 (guest, #168201) [Link] (9 responses)

Yes, really. The problem, fundamentally, isn’t the new 200 lines of code. It is the unauditable mess of the rest of the dependencies that are now to be linked in to a program *designed* to allow unprivileged users to escalate privileges.

Sudo and its alternatives

Posted Feb 21, 2024 23:23 UTC (Wed) by bluca (subscriber, #118303) [Link] (8 responses)

> Yes, really. The problem, fundamentally, isn’t the new 200 lines of code. It is the unauditable mess of the rest of the dependencies that are now to be linked in to a program *designed* to allow unprivileged users to escalate privileges.

Polkit has been providing the escalating privileges functionality on Linux for almost 20 years now. It's had its fair share of problems, like any other software, but it is in no way an "unauditable mess", in fact, having recently done some substantial work to improve its robustness and modernize it, its core is pretty well reviewable. It's not in any way worse than larger components such as the kernel, both from the point of view of the size and also for the number of issues that affect it. In fact, I haven't counted but I am willing to bet the Linux kernel gets more high severity CVEs in any given year than polkit did in its entire lifetime.

I have no idea what some rant about screensavers has to do with sudo and its replacements, sorry but you lost me there.

Sudo and its alternatives

Posted Feb 21, 2024 23:57 UTC (Wed) by marcus0x62 (guest, #168201) [Link] (7 responses)

The “rant” was about how an overly complex design for a critical security problem will inevitably lead to vulnerabilities, simply because it gets harder and harder to reason about behavior accurately (or proactively find and eliminate exploitable bugs) as complexity increases. Both the screen locker and sudo/doas/uid0 have the *potential* of failing open - that is to say, to grant more privilege than they should in a failure state.

Sudo and its alternatives

Posted Feb 22, 2024 0:24 UTC (Thu) by bluca (subscriber, #118303) [Link] (6 responses)

> The “rant” was about how an overly complex design for a critical security problem will inevitably lead to vulnerabilities, simply because it gets harder and harder to reason about behavior accurately (or proactively find and eliminate exploitable bugs) as complexity increases.

"Overly complex design" is usually a code word for "some stuff I haven't really looked into but I know I don't like", usually because "back in my day we used to punch holes in cards with a toothpick" or something along those lines.

> Both the screen locker and sudo/doas/uid0 have the *potential* of failing open - that is to say, to grant more privilege than they should in a failure state.

Code for all three of those is available to be cloned, so if you want to provide some proof for that statement, now would be the ideal time to do so.

Sudo and its alternatives

Posted Feb 23, 2024 0:06 UTC (Fri) by marcus0x62 (guest, #168201) [Link] (5 responses)

> Code for all three of those is available to be cloned, so if you want to provide some proof for that statement, now would be the ideal time to do so.

If you honestly believe that there is no potential for these programs to fail open - as sudo has in the past due to exploitable vulnerabilities - or if you simply do not understand what ‘potential’ means, I cannot help you.

Sudo and its alternatives

Posted Feb 23, 2024 0:24 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> as sudo has in the past due to exploitable vulnerabilities

If you look at sudo vulnerabilities ( https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo ), a significant share of them is caused by failing to properly sanitize the environment.

uid0 is much more resilient against these kinds of attacks, because it starts from a known-good state and then drops privileges as needed. Not vice versa.

Is it possible that uid0 missed something? Sure. But it's far less likely.

Sudo and its alternatives

Posted Feb 23, 2024 0:31 UTC (Fri) by bluca (subscriber, #118303) [Link] (3 responses)

Also every single piece of software that was ever written has "potential" for bugs. It's not a useful thing to say, as it's a tautology. The useful thing is, are there any actual bugs? If so, please point them out and we'll fix them

Sudo and its alternatives

Posted Feb 23, 2024 6:35 UTC (Fri) by mb (subscriber, #50428) [Link] (2 responses)

But for some software the "potential" is higher than for others.
E.g. because they are written in unsafe languages or they don't use frameworks like systemd that bring applications into a known consistent startup state.
Just looking at actual bugs is not enough. We have done that for decades and failed miserably.
We have to make bugs harder to happen by design.

Sudo and its alternatives

Posted Feb 23, 2024 18:26 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (1 responses)

> We have to make bugs harder to happen by design.

No, that's the mistake that has been done for a long time and it has not helped, it transforms language bugs into logic bugs because doing the right stuff gets more difficult.

What is needed is to make it easier to do the right thing. Due to this, bugs will be harder.

I would love to see a C standard variant with all UBs clearly defined to safe and intuitive values (mostly what the kernel sets with all its options in fact). *That* would make bugs less likely to happen and more detectable. But others tried in the past and it always ends up in bikeshedding.

Sudo and its alternatives

Posted Feb 25, 2024 21:18 UTC (Sun) by matthias (subscriber, #94967) [Link]

> I would love to see a C standard variant with all UBs clearly defined to safe and intuitive values

What are safe and intuitive values if you do out of bounds access, use after free, data races, etc.? Most of the UB is there because it is actually UB on the hardware level.

Of course there is some UB in C that can be reasonably defined (e.g., signed integer overflow). But most security critical bugs are memory safety errors. And these cannot be defined away. If you want to get rid of these you need ownership tracking (the rust way), garbage collection (the java way) or some other runtime tracking (e.g., only allow reference counted pointers).

Sudo and its alternatives

Posted Feb 21, 2024 20:08 UTC (Wed) by pizza (subscriber, #46) [Link]

> So with uid0, to become root you simply need: systemd, dbus and polkit which itself needs a JavaScript interpreter. So simple!

Psst, you left out Linux from your dependency list. Kinda hard to run systemd without Linux. Oh, and a C library. And (probably) a couple dozen other libraries and utilities for a minimally-useful system.

Sudo and its alternatives

Posted Feb 22, 2024 8:33 UTC (Thu) by chris_se (subscriber, #99706) [Link] (20 responses)

> polkit which itself needs a JavaScript interpreter.

While don't like that polkit switched to JavaScript either, I think the 'attack surface' claim in this context is dramatically overstated:

1. Nowadays https://duktape.org/ is used instead of a browser engine, so polkit itself doesn't actually have that big of a footprint anymore.
2. It's not like polkit is executing JavaScript code written by a potential attacker - it's executing JavaScript code that was written by the maintainers of the distribution of by the local sysadmin.

Would I have preferred if polkit didn't go and use JavaScript? Sure. But I have neither the time nor the energy to write something better that fulfills the same need. And I think polkit is a net positive when it comes to security, because it does allow for standardized fine-grained access control for IPC. (Want to give a service on an embedded appliance the ability to reboot the appliance without giving the service complete root privileges? Trivial with systemd + polkit. Very hard to get right with other means.)

Sudo and its alternatives

Posted Feb 22, 2024 10:11 UTC (Thu) by atnot (guest, #124910) [Link] (17 responses)

I personally would much rather have javascript than whatever layers of incantations e.g. PAM is doing.

Aside from having a bad reputation with a certain smug crowd, javascript is a pretty good choice if you're going to have a plugin system. It's widespread, well known, has a decent ecosystem (unlike e.g. lua), has many implementations and is easily sandboxed (unlike e.g. python). And using a sandboxed scripting language is just way more secure, auditable and sensible in a security critical tool than the dlopening random C DSOs or execveing bash scripts shenanigans. Or worse, that in combination with some poorly defined, ever growing, adhoc config language. Which is what we would be doing otherwise. But of course none of that matters, because JavaScript is not a cool language and it's not used by the kids at the cool table, and hence it must be expunged.

Sudo and its alternatives

Posted Feb 22, 2024 12:45 UTC (Thu) by sionescu (subscriber, #59410) [Link] (16 responses)

Why would the size of the ecosystem be relevant ? In this application, no external libraries would be used anyway.

Sudo and its alternatives

Posted Feb 22, 2024 14:03 UTC (Thu) by farnz (subscriber, #17727) [Link] (15 responses)

Firstly, I disagree that no external libraries would be used; they'd be unusual, sure, but in every system I've worked with that allows configuration via code, eventually someone pulls in an external library that does something useful but that's not part of the base language. For example, you might pull in a library that can directly interpret a policy document output by another system, or that can detect out-of-policy decisions and prevent them.

Secondly, a language with a big ecosystem correlates well with a good supply of people who can do quick hacks in that language; at my current job over half the developers have written some JavaScript before, and could usefully write a PolKit configuration as a result, while there's only 2 of us around who have written anything in Lua before.

Sudo and its alternatives

Posted Feb 22, 2024 14:40 UTC (Thu) by sionescu (subscriber, #59410) [Link] (7 responses)

> Firstly, I disagree that no external libraries would be used; they'd be unusual, sure, but in every system I've worked with that allows configuration via code, eventually someone pulls in an external library that does something useful but that's not part of the base language.

I'd expect that such a critical component would disallow the loading of external libraries (even by the sysadmins), and only expose built-in functionality to a tightly controlled execution environment. As such, the richness of the ecosystem is entirely irrelevant.

> Secondly, a language with a big ecosystem correlates well with a good supply of people who can do quick hacks in that language; at my current job over half the developers have written some JavaScript before, and could usefully write a PolKit configuration as a result, while there's only 2 of us around who have written anything in Lua before.

Polkit policies would only concern a very small number of people working on system integration, and the popularity of the language wouldn't be a major requirement.

Sudo and its alternatives

Posted Feb 22, 2024 14:44 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

If it disallows the loading of external code, then you have a serious problem - how exactly am I supposed to configure a system that uses code to configure it, if the system won't load my code?

If it allows loading of external code, I can bundle the external library with my code, and the system can't tell that the external library was downloaded from the Internet rather than written by me.

And the whole reason you have a configuration language for Polkit is that there's lots of different configurations that might make sense; if I have to learn PolKitScript to configure it, then I'm stuck being "the Polkit person"; if it's JavaScript, I can tell someone outside my team to write me the JavaScript for the policy that we want to implement, and simply review it, rather than having to write it as well.

Sudo and its alternatives

Posted Feb 22, 2024 15:00 UTC (Thu) by sionescu (subscriber, #59410) [Link] (1 responses)

> If it disallows the loading of external code, then you have a serious problem - how exactly am I supposed to configure a system that uses code to configure it, if the system won't load my code?
> If it allows loading of external code, I can bundle the external library with my code, and the system can't tell that the external library was downloaded from the Internet rather than written by me.

I invite you to take a look at the docs: https://www.freedesktop.org/software/polkit/docs/latest/p...

The execution environment exposes a few objects which allow defining some very limited hooks. There doesn't seem to be any support for require(), nor I/O, perhaps not even named functions. That makes it practically impossible to use third party libraries except by doing copy-and-paste of non-I/O functionality (perhaps string manipulation, etc...).

Sudo and its alternatives

Posted Feb 22, 2024 15:25 UTC (Thu) by farnz (subscriber, #17727) [Link]

The ability to copy-and-paste non-I/O functionality is, however, extremely useful; I can (to choose an example) include a "JSON database" in my rules, automatically generated from a source in an interesting fashion, and with fast programmatic queries relying on indexes that come as JavaScript code. Indeed, I may even have the code to generate this already for use in (e.g.) a web front end, and I just have to tell it that I want a bigger database than it normally sends.

On top of that, I have syntax highlighters, lint tools, transpilers targeting JS (e.g. I could write the rules in TypeScript and transpile) and much more available to me, none of which would exist if I used PolKitScript instead.

Sudo and its alternatives

Posted Feb 22, 2024 14:47 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> I'd expect that such a critical component would disallow the loading of external libraries (even by the sysadmins), and only expose built-in functionality to a tightly controlled execution environment. As such, the richness of the ecosystem is entirely irrelevant.

Okay, instead of loading an external LDAP (or OATH2 or whatever) authentication library with custom hooks into your local deployment, it has to be "built in".

That arbitrary library still has to be written either way, and it's more likely to be written (ie by someone other than the original upstream) if the language chosen has a "richer ecosystem".

Sudo and its alternatives

Posted Feb 22, 2024 15:03 UTC (Thu) by sionescu (subscriber, #59410) [Link] (2 responses)

> Okay, instead of loading an external LDAP (or OATH2 or whatever) authentication library with custom hooks into your local deployment, it has to be "built in".

> That arbitrary library still has to be written either way, and it's more likely to be written (ie by someone other than the original upstream) if the language chosen has a "richer ecosystem".

See my comment above: https://lwn.net/Articles/963210/

I'd expect the environment to expose some C library bindings, so again the language ecosystem is largely unimportant.

Sudo and its alternatives

Posted Feb 22, 2024 15:11 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> I'd expect the environment to expose some C library bindings, so again the language ecosystem is largely unimportant.

If you're using C library bindings, then you're effectively making everything "built-in functionality" which limits you to the "language ecosystems" that can be linked into a single executable.

(And if you're going to alllow calling external binaries, then what exactly was your point about "disallowing the loading of external libraries"?)

Sudo and its alternatives

Posted Feb 22, 2024 15:17 UTC (Thu) by sionescu (subscriber, #59410) [Link]

> If you're using C library bindings, then you're effectively making everything "built-in functionality" which limits you to the "language ecosystems" that can be linked into a single executable.

Yes, but in this case it's mostly the C/C++ ecosystem (or whatever can produce an ELF object).

> (And if you're going to alllow calling external binaries, then what exactly was your point about "disallowing the loading of external libraries"?)

Because the third-party libraries that would be linked into Polkit would be strictly controlled by the upstream authors of Polkit, not under the control of sysadmins, so it would be impossible to edit a Polkit rule and load arbitrary code. A very common pattern after all: define a set of core primitives that one exports into a very limited "scripting" environment, that gets interpreted and mostly allows defining some hooks.

Sudo and its alternatives

Posted Feb 22, 2024 15:22 UTC (Thu) by atnot (guest, #124910) [Link] (4 responses)

There's another aspect I was thinking of, which is stuff like editor integration, language servers, linters, formatters, automated refactoring etc. JS has so many of each of these that it's arguably becoming a problem. In Lua you'd be lucky to find any of these that's maintained, works with your version and is packaged in distros, nevermind being nice to use.

As an aside, that's not just a question of userbase, but also being a language that's used to write and maintain substantial codebases. There is an absolute ton of Lua out there in the world, but most of it is written by people who wouldn't consider coding their main job, e.g. people writing narratives/quests or designing gameplay mechanics for video games. Most of that code is written in very bespoke programming environments that don't really flow back to the community and is never touched again once it works anyway. Ditto for stuff like Cloudflare's WAF rules. There's just nobody out there who cares that much about Lua code quality.

Sudo and its alternatives

Posted Feb 22, 2024 15:24 UTC (Thu) by sionescu (subscriber, #59410) [Link] (3 responses)

Just take a look at actual rules. They're so simple that you effectively don't need any of that. Some syntax highlighting is enough.

Sudo and its alternatives

Posted Feb 22, 2024 15:27 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

I have looked at Polkit rules in the past - if you're genuinely saying that you can navigate a multi-megabyte codebase that uses a minifier to reduce it down to one file without any tooling, well then, hats off to you.

Maybe it was never meant to be this complex, but I've seen it done, and it would have been done in PolKitScript instead if Polkit didn't use JavaScript, just with custom tooling instead of the tools everyone uses.

Sudo and its alternatives

Posted Feb 22, 2024 17:44 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (1 responses)

What… what are you talking about? I have few rules and each of them is couple hundred bytes logs, with copious comments included.
Where did you saw multi-megabyte minified polkit rules?

Sudo and its alternatives

Posted Feb 22, 2024 21:34 UTC (Thu) by farnz (subscriber, #17727) [Link]

A place that was mostly a Microsoft shop, where they'd found a way to dump out the full GPOs as JSON via some third party tool, scripted it, and written JavaScript that read in the GPOs and applied the appropriate subset as Polkit permissions.

Utterly insane, but possible because Polkit's config system was fairly flexible - and a lot better than the suggested alternative from their IT team of porting from Linux to Windows 2000 as the then-current Windows version.

Sudo and its alternatives

Posted Feb 22, 2024 23:06 UTC (Thu) by ceplm (subscriber, #41334) [Link] (1 responses)

> eventually someone pulls in an external library that does something useful but that's not part of the base language

OK, that’s a good reason why NOT to use a language which allows it. Pulling external (unaudited) libraries to your authorization toolkit is just so bad idea …

Sudo and its alternatives

Posted Feb 23, 2024 10:45 UTC (Fri) by farnz (subscriber, #17727) [Link]

I didn't say unaudited - you can audit your external libraries as you pull them into the system. Pulling in unaudited code to a security-relevant codebase is a fool's errand, but it's still a lot easier to audit an external library that does what you need than to write a secure version yourself taking into account all the edge cases.

Sudo and its alternatives

Posted Feb 22, 2024 18:31 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (1 responses)

> it's executing JavaScript code that was written by ... the local sysadmin

Hello, a local sysadmin here. As someone who has once written "=" instead of "==" I can testify that JavaScript and security policies don't mix too well.

Sudo and its alternatives

Posted Feb 22, 2024 22:21 UTC (Thu) by bookworm (subscriber, #114190) [Link]

you are still missing one equals sign XD

https://developer.mozilla.org/en-US/docs/Web/JavaScript/E...

Sudo and its alternatives

Posted Feb 22, 2024 20:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I've written several authz engines in my career, and my personal belief is that you need an almost Turing-complete language to express authorization rules. Systems that try to do that purely declaratively always end up being horrifying messes of ad-hoc features (AWS IAM, I'm looking at YOU!).

And if you're going to use a Turing-complete language, then JavaScript is as good as any other choice. I personally would have chosen Lua, but whatever. JS is good enough.

Keep in mind, that it does not need to deal with untrusted source code, because policies are shipped as a part of the packages that use them. In that regard, they are similar to /etc/sudoers.