[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.21.2008120643370.10591@namei.org>
Date: Wed, 12 Aug 2020 07:03:12 +1000 (AEST)
From: James Morris <jmorris@...ei.org>
To: Chuck Lever <chucklever@...il.com>
cc: Mimi Zohar <zohar@...ux.ibm.com>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Deven Bowers <deven.desai@...ux.microsoft.com>,
Pavel Machek <pavel@....cz>, Sasha Levin <sashal@...nel.org>,
snitzer@...hat.com, dm-devel@...hat.com,
tyhicks@...ux.microsoft.com, agk@...hat.com,
Paul Moore <paul@...l-moore.com>,
Jonathan Corbet <corbet@....net>, nramas@...ux.microsoft.com,
serge@...lyn.com, pasha.tatashin@...een.com,
Jann Horn <jannh@...gle.com>, linux-block@...r.kernel.org,
Al Viro <viro@...iv.linux.org.uk>,
Jens Axboe <axboe@...nel.dk>, mdsakib@...rosoft.com,
open list <linux-kernel@...r.kernel.org>, eparis@...hat.com,
linux-security-module@...r.kernel.org, linux-audit@...hat.com,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-integrity@...r.kernel.org,
jaskarankhurana@...ux.microsoft.com
Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement
LSM (IPE)
On Sat, 8 Aug 2020, Chuck Lever wrote:
> My interest is in code integrity enforcement for executables stored
> in NFS files.
>
> My struggle with IPE is that due to its dependence on dm-verity, it
> does not seem to able to protect content that is stored separately
> from its execution environment and accessed via a file access
> protocol (FUSE, SMB, NFS, etc).
It's not dependent on DM-Verity, that's just one possible integrity
verification mechanism, and one of two supported in this initial
version. The other is 'boot_verified' for a verified or otherwise trusted
rootfs. Future versions will support FS-Verity, at least.
IPE was designed to be extensible in this way, with a strong separation of
mechanism and policy.
Whatever is implemented for NFS should be able to plug in to IPE pretty
easily.
--
James Morris
<jmorris@...ei.org>
Powered by blists - more mailing lists