On 12/05/2020 22:46, Deven Bowers wrote:

On 5/11/2020 11:03 AM, Deven Bowers wrote:

quoted

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

[...snip]

quoted

quoted

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.

I have not found a way that I like to expose some kind of grammar
through securityfs that can be understood by usermode to parse the
policy. Here's what I propose as a compromise:

    1. I remove the unknown command behavior. This address your
first point about inconsistent behaviors, and effectively removes the
strict_parse sysctl (as it is always enabled).

    2. I introduce a versioning system for the properties
themselves. The valid set of properties and their versions
can be found in securityfs, under say, ipe/config in a key=value
format where `key` indicates the understood token, and `value`
indicates their current version. For example:

    $ cat $SECURITYFS/ipe/config
    op=1
    action=1
    policy_name=1
    policy_version=1
    dmverity_signature=1
    dmverity_roothash=1
    boot_verified=1

The name ipe/config sounds like a file to configure IPE. Maybe something
like ipe/config_abi or ipe/config_grammar?

if new syntax is introduced, the version number is increased.

    3. The format of those versions are documented as part of
the admin-guide around IPE. If user-mode at that point wants to rip
the documentation formats and correlate with the versioning, then
it fulfills the same functionality as above, with out the complexity
around exposing a parsing grammar and interpreting it on-the-fly.
Many of these are unlikely to move past version 1, however.

Thoughts?

That seems reasonable.