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