remove polkit from core?

Steve Grubb sgrubb at redhat.com
Tue Nov 13 14:37:07 UTC 2012


On Tuesday, November 13, 2012 12:50:11 PM Alek Paunov wrote:
> Hi Steve,
> 
> On 12.11.2012 21:00, Steve Grubb wrote:
> > 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.
> 
> My question is: Whether be acceptable the required compliance analysis
> to be performed on rules written in simplified rule language like
> Datalog instead of imperative scripted evaluation in some future version
> of polkit ... ?

The standard that everyone is embracing for compliance checking is called 
SCAP. Parts of it are also being looked at by the IETF for standardization, 
too. I did a presentation on SCAP for the aqueduct project here:

https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech-
talk.pdf

XCCDF represents the policy that you wish to enforce. It is abstract in that 
it does not know exactly what file to access or how to perform the check. That 
is the job of OVAL, which is concrete in that it has the exact tests and knows 
which file to look at.

The OVAL language has a number of checking mechanisms:

http://oval.mitre.org/language/version5.10.1/OVAL_Language_Specification_01-20-2012.pdf

For anything with name=value, we normally use the textfilecontent54 which we 
can define a regex to pick out the items of interest. However, with a language, 
you have multiple ways of expressing the same idea. for example,

if (foo() > 500)

and

uid = foo();
if (uid > 500)

and

start = 500;
uid = foo();
if (uid > start)

do the same thing. Then throw in comments and indentation and it you have lots 
of possibilities. This is also not considering whether the code actually meets 
the intent or allows unintended functionality (exploits).

The only thing I can think of, using what's currently available in SCAP is to 
use filehash58 and call it a day. This has the drawback of notifying the admin 
that the hash doesn't match instead of a useful, actionable, message. They 
will be left wondering why the hash doesn't match and what they can do to fix 
it.

This is not going to help security. This should be a lesson to anyone wanting 
to adopt a languge for system configuration and policy decision.


> (It seems to me that e.g. Datalog is good enough both as flexibility and
> static analysis (symbolic evaluation), furthermore IMO declarative rules
> are less error prone for sysadmins than scripting)

Do you have a reference for it? I would almost think that you would want to 
specify system access rights in a Formal Language which supports the notion of 
proofs if anything like this were done. In that event, standards work would 
have to be done in preparation for this. I sit on the OVAL editorial Board, so 
I could raise the issue to the Board. But javascript for access control policy 
is a train wreck for anyone needing to demonstrate compliance.

-Steve


More information about the devel mailing list