Re: [RFC PATCH v3 00/12] Integrity Policy Enforcement LSM (IPE)

[Deven Bowers]

On 5/10/2020 2:28 AM, Mickaël Salaün wrote:

[...snip]

> > Additionally, rules are evaluated top-to-bottom. As a result, any
> > revocation rules, or denies should be placed early in the file to ensure
> > that these rules are evaluated before a rule with "action=ALLOW" is hit.
> >
> > IPE policy is designed to be forward compatible and backwards compatible,
> > thus any failure to parse a rule will result in the line being ignored,
> > and a warning being emitted. If backwards compatibility is not required,
> > the kernel commandline parameter and sysctl, ipe.strict_parse can be
> > enabled, which will cause these warnings to be fatal.
>
> Ignoring unknown command may lead to inconsistent beaviors. To achieve
> forward compatibility, I think it would be better to never ignore
> unknown rule but to give a way to userspace to known what is the current
> kernel ABI. This could be done with a securityfs file listing the
> current policy grammar.

That's a fair point. From a manual perspective, I think this is fine.
A human-user can interpret a grammar successfully on their own when new
syntax is introduced.

From a producing API perspective, I'd have to think about it a bit 
more. Ideally, the grammar would be structured in such a way that the 
userland
interpreter of this grammar would not have to be updated once new syntax
is introduced, avoiding the need to update the userland binary. To do so
generically ("op=%s") is easy, but doesn't necessarily convey sufficient
information (what happens when a new "op" token is introduced?). I think
this may come down to regular expression representations of valid values
for these tokens, which worries me as regular expressions are incredibly
error-prone[1].

I'll see what I can come up with regarding this.


[1] 
https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/