Sudo and its alternatives

Posted Feb 22, 2024 10:11 UTC (Thu) by atnot (guest, #124910)
In reply to: Sudo and its alternatives by chris_se
Parent article: Sudo and its alternatives

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.

to post comments

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.