Linux-Security-Module Archive on
 help / color / Atom feed
From: "Mickaël Salaün" <>
To: Jaskaran Singh Khurana <>
Cc: Deven Bowers <>,,,,,,,,,,,,,,,,,,
Subject: Re: [RFC PATCH v3 00/12] Integrity Policy Enforcement LSM (IPE)
Date: Fri, 29 May 2020 10:18:36 +0200
Message-ID: <> (raw)
In-Reply-To: <alpine.LRH.2.21.2005161420490.8455@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.inter>

Hi Jaskaran,

On 17/05/2020 00:14, Jaskaran Singh Khurana wrote:
> Hello Mickael,
> On Thu, 14 May 2020, Mickaël Salaün wrote:
>> On 12/05/2020 22:46, Deven Bowers wrote:
>>> On 5/11/2020 11:03 AM, Deven Bowers wrote:
>>>> 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.
>>> 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.
> 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.

What can be done in the kernel to ignore some policy rules could also be
done in a tool managing different policies. For instance, a simple tool
can instantiate a human-written policy into multiple backward compatible
policies (according to different versions of supported kernels). The
appropriate policy could then be fetched on the fly by the nodes or
pushed by an orchestration system.

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

With your constraints in mind, I still think that flexible policy
management can be achieved with strict kernel policy parsing. The
complexity should be handled by infrastructure management system.

> Regards,
> JK

      parent reply index

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 16:25 deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 01/12] scripts: add ipe tooling to generate boot policy deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 02/12] security: add ipe lsm evaluation loop and audit system deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 03/12] security: add ipe lsm policy parser and policy loading deven.desai
2020-07-15 19:16   ` Tyler Hicks
2020-04-15 16:25 ` [RFC PATCH v3 04/12] ipe: add property for trust of boot volume deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 05/12] fs: add security blob and hooks for block_device deven.desai
2020-04-22 16:42   ` James Morris
2020-04-22 16:55     ` Casey Schaufler
2020-04-15 16:25 ` [RFC PATCH v3 06/12] dm-verity: move signature check after tree validation deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 07/12] dm-verity: add bdev_setsecurity hook for dm-verity signature deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 08/12] ipe: add property for signed dmverity volumes deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 09/12] dm-verity: add bdev_setsecurity hook for root-hash deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 10/12] ipe: add property for dmverity roothash deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 11/12] documentation: add ipe documentation deven.desai
2020-04-15 16:25 ` [RFC PATCH v3 12/12] cleanup: uapi/linux/audit.h deven.desai
2020-05-10  9:28 ` [RFC PATCH v3 00/12] Integrity Policy Enforcement LSM (IPE) Mickaël Salaün
2020-05-11 18:03   ` Deven Bowers
2020-05-12 20:46     ` Deven Bowers
2020-05-14 19:28       ` Mickaël Salaün
2020-05-16 22:14         ` Jaskaran Singh Khurana
2020-05-26 20:44           ` Jaskaran Singh Khurana
2020-05-29  8:18           ` Mickaël Salaün [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Security-Module Archive on

Archives are clonable:
	git clone --mirror linux-security-module/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-security-module linux-security-module/ \
	public-inbox-index linux-security-module

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone