remove polkit from core?
Steve Grubb
sgrubb at redhat.com
Mon Nov 12 19:00:41 UTC 2012
On Monday, November 12, 2012 12:27:52 PM Dan Williams wrote:
> On Sat, 2012-11-10 at 02:33 +0100, Kevin Kofler wrote:
> > Matthew Miller wrote:
> > > Apparently the new version of polkit brings in javascript. The js
> > > package
> > > is 6.5MB. I think anything that uses polkit will depend on it -- can we
> > > remove it from core?
> >
> > Of course, the real question is why the heck PolicyKit needs a Turing-
> > complete rule language (which also forced everyone to port their existing
> > rules) when the previously-used simple INI-style pkla rule format did the
> > job just fine!
>
> So that more complex rules-parsing can be done instead of hardcoded
> rules. For example, when creating a new WiFi network, NetworkManager
> could pass along the security options, network details, even the user
> that requested creating it. Administrator-written rules can factor all
> those details into the decision whether to allow/deny, which the
> existing static rules simply cannot do.
except that most admins will never be able to do this. The only people that
get any flexibility are people who manage their own system. Everyone else
likely has some compliance issues and they have to be verifiably in
configuration. What will happen is the generic js file will be SHA256 hashed and
we'll check the file's hash in SCAP and report the system as out of
configuration.
IOW, anyone running any sizeable operation just lost any flexibility.
> Whether or not JS should be a *hard* dependency of PolicyKit, I don't
> know. But the feature is valuable, so don't dismiss it out-of-hand.
I think its a bad idea to have too much flexibility for access control systems.
They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG
or any other standard, you have to be able to demonstrate you are in the
approved config. No one can write a test that can tell if the rules really are
sound. So, what will happen is one set will be chosen for better or worse, it
will be SHA256 hashed. And no one can change anything in it without being out
of compliance.
The benefit of the name=value setup is that we can pick out the things that
matter and skip everything else which truly gives flexibility when needing to
demonstrate compliance.
-Steve
More information about the devel
mailing list