Hello Mickael,

Could you please share your thoughts for the below proposal.

Regards,
JK

On Sat, 16 May 2020, Jaskaran Singh Khurana wrote:

Hello Mickael,

On Thu, 14 May 2020, Mickaël Salaün wrote:

quoted

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

quoted

 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?

quoted

 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.

There is a use case for not having strict parsing in the cloud world where 
there are multiple versions of OS deployed across a large number of systems 
say 100,000 nodes. An OS update can take weeks to complete across all the 
nodes, and we end up having a heterogeneous mix of OS versions.

Without non-strict parsing, to fix an issue in a policy we will need to 
update the various versions of the policy (one each for all OS versions
which have different IPE policy schema). We will lose the agility we need to 
fix and deploy something urgently in the policy, the nodes might be failing 
some critical workloads meanwhile. All the various versions of the policy 
will need to be changed and production signed then deployed etc. Further some 
versions might introduce newer issues and we will need to see what all 
versions of the policy have that bug.

I propose keeping the non-strict option as well to cater to this use case. 
Let me know your thoughts on this.

Regards,
JK