remove polkit from core?

[Steve Grubb]

On Tuesday, November 13, 2012 02:07:53 PM Matthias Clasen wrote:
> ----- Original Message -----
> 
> > So, talking about specific actions...
> > 
> > I have recently had to search all existing polkit policies.  This is
> > no longer possible to automate because various packages ship the
> > JavaScript policy, so I had to review those by hand.  It seems that
> > (perhaps with the exception of polkit itself) any use of JavaScript
> > could be converted into the old format, which remains supported.
> > 
> > So, as soon I find some free time (probably next week), I intend to
> > ask FPC to prohibit using JavaScript if the functionality can be
> > represented in the old .pkla, and to prepare patches to convert the 6
> > JS-using packages.
> 
> Not sure where you got that information. pkla files are not supported
> anymore.
> 
> So, converting JavaScript rules to pkla syntax won't do any good. What is
> worthwhile doing though, is to review all existing packages that ship such
> rules, and stop them from doing that, if possible. JavaScript rules are
> only meant for admin use, no OS-provided package should install them. We
> only look in /usr/share to allow for the possibility of site-local
> configuration that is distributed in packages.

Turning system configuration into a scriptable language is like going back in 
time to the 70's and early 80's where you modified the source to have a 
different behavior. Remember Basic programs where if you wanted it to do 
something new, you change your copy so its better that the one people were 
sharing?

It was decided a long time ago that its better to just have a parser that 
looks for the things that people would commonly like to change. This way, you 
have some assurance that the main binary has some integrity and you didn't 
make some kind of typo that opens access for the world.

As a matter of fact, the better way to do this is via some kind of daemon that 
keeps all this information in one giant database. This way its possible to 
audit any change to the database and know who did it, what they changed, and 
what the old and new values are. This level of service was asked for by 
government agencies. We pointed to the sshd config file and said its impossible. 
I canplace a watch on the file and I can tell you who changed it and I can tell 
you when they changed it, but I cannot tell you what in it changed.

This is the direction I'd rather see the OS go instead of going back to what 
amounts to changing the source code. We need to improve the verifiablity rather 
than the flexibility.


> A concrete action that we are going to take is to split the polkit daemon
> into its own subpackage. Then minimal / certifiable installs can contain
> clients that are using the polkit libraries, without pulling in the daemon.
> Polkit clients are already expected to handle this situation and fall back
> to allow only uid 0. All of this is documented in
> 
> http://www.freedesktop.org/software/polkit/docs/latest/polkit-apps.html

We have security configurations for desktop systems. This proposal fixes the 
minimal install issue but does not address the compliance issue.

-Steve

http://en.wikipedia.org/wiki/Configuration_file