From: Deven Bowers <deven.desai@linux.microsoft.com>
To: "Mickaël Salaün" <mic@digikod.net>,
agk@redhat.com, axboe@kernel.dk, snitzer@redhat.com,
jmorris@namei.org, serge@hallyn.com, zohar@linux.ibm.com,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org, dm-devel@redhat.com,
linux-block@vger.kernel.org, jannh@google.com
Cc: tyhicks@linux.microsoft.com, pasha.tatashin@soleen.com,
sashal@kernel.org, jaskarankhurana@linux.microsoft.com,
nramas@linux.microsoft.com, mdsakib@linux.microsoft.com,
linux-kernel@vger.kernel.org, corbet@lwn.net
Subject: Re: [RFC PATCH v3 00/12] Integrity Policy Enforcement LSM (IPE)
Date: Mon, 11 May 2020 11:03:31 -0700 [thread overview]
Message-ID: <0001755a-6b2a-b13b-960c-eb0b065c8e3c@linux.microsoft.com> (raw)
In-Reply-To: <b07ac7e1-7cf5-92c9-81d0-64174c3d5024@digikod.net>
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/
next prev parent reply other threads:[~2020-05-11 18:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 16:25 [RFC PATCH v3 00/12] Integrity Policy Enforcement LSM (IPE) 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 [this message]
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
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0001755a-6b2a-b13b-960c-eb0b065c8e3c@linux.microsoft.com \
--to=deven.desai@linux.microsoft.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=dm-devel@redhat.com \
--cc=jannh@google.com \
--cc=jaskarankhurana@linux.microsoft.com \
--cc=jmorris@namei.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mdsakib@linux.microsoft.com \
--cc=mic@digikod.net \
--cc=nramas@linux.microsoft.com \
--cc=pasha.tatashin@soleen.com \
--cc=sashal@kernel.org \
--cc=serge@hallyn.com \
--cc=snitzer@redhat.com \
--cc=tyhicks@linux.microsoft.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).