Replacing polkit JS backend

[Miloslav Trmac]

Hello,
2017-12-18 11:05 GMT+01:00 Colin Walters <walters at verbum.org>:

> Based on some (long ago now) in-person discussion with the previous polkit
> maintainer:
> the JS backend was added for a reason from a real-world nontrivial in size
> desktop deployment.
> That said I don't have contact with them myself and unfortunately the
> original commit
> aeb2b50a7b0ed1411df81790231cd902d6e76e56
> doesn't give us any hints.  I wouldn't be surprised if they don't use it
> anymore.
>

I tried tracking this down, and the best public record I can find is that
the JS backend was motivated by
https://bugs.freedesktop.org/show_bug.cgi?id=30181 , i.e. just adding the
"other" field in the UNIX user/group/other ACL format — which was a pretty
small patch compared to the JS backend (and polkit-pkla-compat does add
that small patch).


Philosophically I think that most permissions on the system should mostly
really be handled by a pretty dumb ACL library, with ACLs „attached to“ the
individual objects they apply to (e.g. a printer daemon would record ACLs
for printing to printers and managing the printer, and a global ACL for
printer management). It should not look even a *tiny bit* like something
programmable (once it is a *tiny* bit programmable, there will always be a
good argument to make it *yet another tiny bit more* programmable, and we
are back to Turing-completeness).

An audit tool should be able to statically and 100% reliably tell whether
$operation is allowed to $user. Any Turing-complete, or less programmable
but complex, model, makes writing such audit tools very hard to impossible.

Given an ACL library, a system-wide daemon may not even be necessary for
evaluating ACLs as such; we would have a daemon for things like "is
interactively logged in" and exposing them to the ACL system as
pseudo-groups or something like that (and of course daemons for privilege
escalations, e.g. to start D-Bus services running as root which can be used
by non-root clients).

Yes, this is pretty similar to the Windows NT design back from….

Disclaimer: I haven’t extensively researched the academic literature, nor
other permission models (and their later evolution like Windows restricted
tokens) in this area. I may well be completely wrong about what is a good
or reasonable design.



> At a practical level I think we'd have to ship both (really all 3) things
> for a while
> at least in Fedora; e.g.
> https://goldmann.pl/blog/2012/12/03/configuring-polkit-in-
> fedora-18-to-access-virt-manager/
> and
> https://major.io/2015/04/11/run-virsh-and-access-libvirt-
> as-a-regular-user/
> and variants are commonly used (I use that JS rule on this workstation
> too).
>

Sadly, it’s not “for a while”. There is no practical path to migrate away
from the JS backend *at all*. JS rules have the ability to ”reject” an
action, so it is not *in general* safe to ignore a rule which has been
installed by an user, and JS is Turing-complete, so we have no way to tell
whether a *particular* rule is safe to ignore either.

So, given an existing installed system which uses JS rules, we can:

   - (Replace unmodified JS rules installed by a RPM or similar package by
   updating to a new version of the RPM which drops the JS file and uses the
   replacement format. Does not help with unpackaged software and private
   configuration.)
   - (Have *some* crazy heuristics to parse JS code and try to convert it
   into equivalent rules in the new format. Very fragile, may work some of the
   time, but is not sufficient in general.)
   - Just ignore the JS rules, potentially allowing something the user
   disabled and needs to keep disabled. Absolutely unacceptable.
   - If we see any JS rule, close down polkit *completely* and reject any
   action by any user, or at best reject any action not done by UID 0. That
   pretty much kills the machine.

So, AFAICT, for better or worse, distributions which already ship the JS
backend are doomed to stay on that backend, unless they are willing to
endure a *horribly* painful flag day. (Shipping two backends “for a while”
does not help because for all that time the JS rules will stay working, not
motivating the users to change, and when the JS rules are finally dropped,
there is a single flag day.)


Of course, new distributions, or constrained projects where all users of
polkit are known and can be converted, are not bound by this and could
benefit from replacing the JS backend. I’m not sure that long-term
bifurcating the ecosystem that way is worth it, though with the existing
Debian split we may already be there. But with Debian staying at .pkla,
maybe the natural other format is .pkla and not something entirely new.
    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/polkit-devel/attachments/20180103/f1931f32/attachment.html>