linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Deven Bowers <deven.desai@linux.microsoft.com>
Cc: corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org,
	serge@hallyn.com, tytso@mit.edu, axboe@kernel.dk, agk@redhat.com,
	snitzer@kernel.org, eparis@redhat.com, paul@paul-moore.com,
	linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org,
	dm-devel@redhat.com, linux-audit@redhat.com,
	roberto.sassu@huawei.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v8 13/17] fsverity: consume builtin signature via LSM hook
Date: Thu, 9 Jun 2022 16:46:57 -0700	[thread overview]
Message-ID: <YqKGcdM3t5gjqBpq@sol.localdomain> (raw)
In-Reply-To: <1654714889-26728-14-git-send-email-deven.desai@linux.microsoft.com>

On Wed, Jun 08, 2022 at 12:01:25PM -0700, Deven Bowers wrote:
> From: Fan Wu <wufan@linux.microsoft.com>
> 
> fsverity represents a mechanism to support both integrity and
> authenticity protection of a file, supporting both signed and unsigned
> digests.
> 
> An LSM which controls access to a resource based on authenticity and
> integrity of said resource, can then use this data to make an informed
> decision on the authorization (provided by the LSM's policy) of said
> claim.
> 
> This effectively allows the extension of a policy enforcement layer in
> LSM for fsverity, allowing for more granular control of how a
> particular authenticity claim can be used. For example, "all (built-in)
> signed fsverity files should be allowed to execute, but only these
> hashes are allowed to be loaded as kernel modules".
> 
> This enforcement must be done in kernel space, as a userspace only
> solution would fail a simple litmus test: Download a self-contained
> malicious binary that never touches the userspace stack. This
> binary would still be able to execute.
> 
> Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
> Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>

The IMA support for fs-verity, which is now upstream, already does this (except
that IMA isn't an LSM).  It also doesn't rely on the fs-verity builtin
signatures, which shouldn't really be used.  Can you elaborate on how what
you're doing is better?

- Eric

  reply	other threads:[~2022-06-09 23:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08 19:01 [RFC PATCH v8 00/17] Integrity Policy Enforcement LSM (IPE) Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 01/17] security: add ipe lsm & initial context creation Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 02/17] ipe: add policy parser Deven Bowers
2022-06-15 22:12   ` Paul Moore
2022-06-08 19:01 ` [RFC PATCH v8 03/17] ipe: add evaluation loop Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 04/17] ipe: add userspace interface Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 05/17] ipe: add LSM hooks on execution and kernel read Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 06/17] uapi|audit: add ipe audit message definitions Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 07/17] ipe: add auditing support Deven Bowers
2022-06-15 22:12   ` Paul Moore
2022-08-09 15:57   ` Tyler Hicks
2022-06-08 19:01 ` [RFC PATCH v8 08/17] ipe: add permissive toggle Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 09/17] ipe: introduce 'boot_verified' as a trust provider Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 10/17] block|security: add LSM blob to block_device Deven Bowers
2022-06-08 20:07   ` Casey Schaufler
2022-06-08 22:28     ` Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 11/17] dm-verity: consume root hash digest and signature data via LSM hook Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 12/17] ipe: add support for dm-verity as a trust provider Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 13/17] fsverity: consume builtin signature via LSM hook Deven Bowers
2022-06-09 23:46   ` Eric Biggers [this message]
2022-06-08 19:01 ` [RFC PATCH v8 14/17] ipe: enable support for fs-verity as a trust provider Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 15/17] scripts: add boot policy generation program Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 16/17] ipe: kunit tests Deven Bowers
2022-06-08 19:01 ` [RFC PATCH v8 17/17] documentation: add ipe documentation Deven Bowers
2022-06-08 19:10 ` [RFC PATCH v8 00/17] Integrity Policy Enforcement LSM (IPE) Matthew Wilcox
2022-06-08 19:41   ` Deven Bowers

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=YqKGcdM3t5gjqBpq@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=agk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=deven.desai@linux.microsoft.com \
    --cc=dm-devel@redhat.com \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=snitzer@kernel.org \
    --cc=tytso@mit.edu \
    --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).