Gregory's Server@pid_eins While I welcome the decision to rely on polkit, I find the indirect dependency on a javascript engine a bit... iffy.
|
14 comments
@pid_eins @phako the JavaScript engine does not process untrusted inputs, only trusted configuration, so it's really not a security problem anyway. People like to talk down js but it's extremely popular and well know and stable and there are tiny engines like duktape, unlike other alternatives with similar properties like lua  @bluca @phako still I think that the right solution here would be to define some minimal IPC rather than choose a programming language for users. I figure the reason why JS was picked here has more to do with the fact that back when PK was designed there was only D-Bus and D-Bus is simply not a great choice if you want to quickly implement an IPC interface. D-Bus is OK to use from a simple client, but it's really hard to use for a simpler server, after all. @pid_eins @phako not really, JS was chosen because you need to be able to express complex configuration rules, and it's better to use a known tool than inventing a new one. It's not about IPC, the transport doesn't matter, you need a configuration-like DSL because it's unfeasible to ask every admin/user to write and deploy a new program every time some rule needs to be adjusted. @bluca @phako I don't see why dropping in a JS-based varlink mini-service would be any harder than dropping in a PK JS fragment. you get a function call with a JS(ON) object, you answer it with a JS(ON) object. done. But by doing this via a Varlink IPC call you gain security (i.e. that stuff runs out of process), and make it generic (i.e. people can chose other languages than JS) @pid_eins @phako because writing a new config file and writing a new running program are not the same thing, and while for us developers there's not much difference, for non-developers the difference is huge. JS was already a though sell because, while the dialect used is minimal and restricted, it's still potentially a full-blown language. Dealing with writing and deploying and maintaining fully independent executables would be way too much. You need dependency tracking, pipelines, etc etc. @bluca @pid_eins @phako writing js is as hard as any other program, and it is turing complete which makes "configuration" uncheckable (unless you solved the halting problem) and this is definitely not good security. A decent basic configuration set + extension via IPC for those extremely rare cases where you would need it (and that you can block) would be much better from a security pov. @bluca @pid_eins @phako Most people can't think adversarially when writing code, which means using js to configure access to a high privileges is very risky. And can't be easily checked for correctness. If you do anything more complex than just assigning variables you risk opening huge holes by not paying attention at how things are evaluated. @simo5 @pid_eins @phako there can be no "decent basic configuration set", that's the point - otherwise it would be there. It's been working like this for a decade, and it's been just fine as it's simple enough do to the variety of basic things that everybody need. The problems aren't there, they are elsewhere, and requiring users and admins to become software developers and supply chain managers is not a realistic or good or desirable solution @bluca @pid_eins @phako there are countless programs that have a simple .ini file for configuration where all you do is set variables. |
@phako well, i am not a fan of that facet of pk either, but I think that's a different problem to tackle. For now, it's *the* local authorization framework on Linux, and all alternatives are worse.