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/
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
