LWN: Comments on "Sudo and its alternatives"

Sudo and its alternatives

ssokolow — Tue, 02 Apr 2024 19:04:01 +0000

However, sudo-rs does call out to Pluggable Authentication Modules (PAM) to authenticate the user, so it can support non-local authentication schemes such as LDAP and Kerberos via the usual Linux mechanism for that.

Also useful for libpam-u2f as a way to add an unblockable blinking indicator (your U2F token's hardware 'touch me' prompt) and physical access requirement for some or all attempts to sneakily use credentials gained from wetware exploits.

Sudo and its alternatives

q_q_p_p — Mon, 26 Feb 2024 22:28:28 +0000

OpenBSD did the right thing by not name-squatting sudo.

Sudo and its alternatives

matthias — Sun, 25 Feb 2024 21:18:36 +0000

> 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).

Please

tedd — Sat, 24 Feb 2024 00:26:02 +0000

Would you like SystemD erotica? https://www.tiltedwindmillpress.com/product/savaged-by-sy...

Sudo and its alternatives

wtarreau — Fri, 23 Feb 2024 18:36:12 +0000

I just read the sudo CVE list that sudo-rs claims wouldn't affect it. I must say that I really find it boring over time to regularly read "safe reimplementation" of whatever, that are deemed safe because all the useful features were dropped. It's as if someone wrote a web server comparing itself to Apache and saying "we don't support modules and we don't even support binding to network by the way, only CGI on stdin, but look at the many CVE that are irrelevant to us".

For example many of CVEs listed indicate "env_reset is always enabled". There are plenty of cases where you precisely need to keep your environment and disable env_reset. It just depends on the use case. Denying users' needs is probably one of the first cause of them trying to work around the limitation with less safe tools and setups. Other funny ones are "noexec bypass" which does not affect it since it does not have noexec functionality. Strictly speaking then it should be considered permanently vulnerable, or the original CVE should not be listed as a comparison. That CVE list comparison looks like a lot of marketing, "my dishwashing liquid washes better".

So sudo-rs may be safe and useful, it just is not a safer sudo, it's just another setuid executable that allows one to do stuff. Maybe it's an extension over "doas" in fact.

Sudo and its alternatives

wtarreau — Fri, 23 Feb 2024 18:26:32 +0000

> 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

smcv — Fri, 23 Feb 2024 12:12:53 +0000

This seems hypocritical, given how they would react if one of their competitors announced an "Excel for Linux" that was actually an unrelated spreadsheet implementation with no code in common...

Sudo and its alternatives

farnz — Fri, 23 Feb 2024 10:45:20 +0000

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

mb — Fri, 23 Feb 2024 06:35:24 +0000

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

bluca — Fri, 23 Feb 2024 00:31:17 +0000

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

Cyberax — Fri, 23 Feb 2024 00:24:40 +0000

> 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

marcus0x62 — Fri, 23 Feb 2024 00:06:30 +0000

> 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

ceplm — Thu, 22 Feb 2024 23:06:12 +0000

> 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

bookworm — Thu, 22 Feb 2024 22:21:03 +0000

you are still missing one equals sign XD

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

Sudo and its alternatives

farnz — Thu, 22 Feb 2024 21:34:09 +0000

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

Cyberax — Thu, 22 Feb 2024 20:33:43 +0000

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.

Sudo and its alternatives

flussence — Thu, 22 Feb 2024 19:18:29 +0000

I'm not sure what you think you're replying to; s6-sudo is part of the service manager.

Sudo and its alternatives

lkundrak — Thu, 22 Feb 2024 18:31:45 +0000

> 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

zdzichu — Thu, 22 Feb 2024 17:44:53 +0000

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

mchouque — Thu, 22 Feb 2024 16:59:21 +0000

My experience with sudo tells me the first problem isn't necessarily sudo's code by itself but the syntax used to configure it.

I have seen so many issues with wildcards: people thinking they're writing some kind of regexes while they're really configuring globbing. Yes, it's documented as such in man 5 sudoers but I've been able to become root so many times because of that it's not even funny.

And if you need to use wildcards and to exclude some uses/arguments, it's often a nightmare to write exclusion rules with '!'.

Sudo and its alternatives

MarcB — Thu, 22 Feb 2024 16:33:11 +0000

Do you really not see the major difference? With sudo, you are elevating privileges out of a potentially malicious environment.
Even if that is handled correctly, this still requires the kernel to implement the privilege elevation functionality in the first place - something it arguably should stop doing.

With uid0, your are branching off of a pre-existing, clean, privileged environment. No privilege elevation is needed, making whole classes of bugs impossible.

btw, some here argue about the complexity of Polkit and Systemd, but completely ignore the complexity that exists to implement setuid/setgid in the kernel and all the hacks in ld.so, ptrace and other places to make it not obviously insecure. There also are some constraints that would not be necessary if those mechanisms would not exist in the first place. For example, unprivileged chroot would be possible (might still break some software, but the breakage would stay within the initial user account).

Sudo and its alternatives

spacefrogg — Thu, 22 Feb 2024 16:17:22 +0000

The service manager already has to do everything that sudo has, just to isolate services from each other and from the rest of the system. And I practically cannot get rid of it. First, it is natural to expose this functionality in a human interface. Second, why would I trust your sudo implementation more than the service manager I already have and already need?

Sudo and its alternatives

farnz — Thu, 22 Feb 2024 15:27:43 +0000

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

farnz — Thu, 22 Feb 2024 15:25:33 +0000

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

sionescu — Thu, 22 Feb 2024 15:24:48 +0000

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

atnot — Thu, 22 Feb 2024 15:22:36 +0000

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

sionescu — Thu, 22 Feb 2024 15:17:00 +0000

> 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

pizza — Thu, 22 Feb 2024 15:11:19 +0000

> 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

sionescu — Thu, 22 Feb 2024 15:03:08 +0000

> 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

sionescu — Thu, 22 Feb 2024 15:00:34 +0000

> 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

pizza — Thu, 22 Feb 2024 14:47:51 +0000

> 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

farnz — Thu, 22 Feb 2024 14:44:34 +0000

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

sionescu — Thu, 22 Feb 2024 14:40:25 +0000

> 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

farnz — Thu, 22 Feb 2024 14:03:32 +0000

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

sionescu — Thu, 22 Feb 2024 12:45:52 +0000

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

What about SSH?

lobachevsky — Thu, 22 Feb 2024 10:52:58 +0000

Thanks for mentioning this! I hadn't noticed that polkit had been split so nicely. Now I can get rid of pkexec while keeping polkitd around.

Please

smitty_one_each — Thu, 22 Feb 2024 10:44:01 +0000

As an April Fool's suggestion, consider an article wherein systemd wakes up one morning and decides to devour the kernel itself.

No, scratch that: LWN is the great place it is because of the high signal-to-noise ratio, and the aforementioned joke article is best left as a hint to the reader's imagination if inclined.

Sudo and its alternatives

atnot — Thu, 22 Feb 2024 10:11:04 +0000

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

chris_se — Thu, 22 Feb 2024 08:33:51 +0000

> 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

bluca — Thu, 22 Feb 2024 00:24:43 +0000

> 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.