From: Chuck Lever <chucklever@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
James Morris <jmorris@namei.org>,
Deven Bowers <deven.desai@linux.microsoft.com>,
Pavel Machek <pavel@ucw.cz>, Sasha Levin <sashal@kernel.org>,
snitzer@redhat.com, dm-devel@redhat.com,
tyhicks@linux.microsoft.com, agk@redhat.com,
Paul Moore <paul@paul-moore.com>,
Jonathan Corbet <corbet@lwn.net>,
nramas@linux.microsoft.com, serge@hallyn.com,
pasha.tatashin@soleen.com, Jann Horn <jannh@google.com>,
linux-block@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
Jens Axboe <axboe@kernel.dk>,
mdsakib@microsoft.com, open list <linux-kernel@vger.kernel.org>,
eparis@redhat.com, linux-security-module@vger.kernel.org,
linux-audit@redhat.com,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-integrity@vger.kernel.org,
jaskarankhurana@linux.microsoft.com
Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)
Date: Thu, 13 Aug 2020 10:56:17 -0400 [thread overview]
Message-ID: <49A45475-20D8-456E-92AD-F63DBC71F900@gmail.com> (raw)
In-Reply-To: <1597329763.3708.13.camel@HansenPartnership.com>
> On Aug 13, 2020, at 10:42 AM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> On Thu, 2020-08-13 at 10:21 -0400, Chuck Lever wrote:
>>> On Aug 12, 2020, at 11:42 AM, James Bottomley <James.Bottomley@Hans
>>> enPartnership.com> wrote:
> [...]
>>> For most people the security mechanism of local xattrs is
>>> sufficient. If you're paranoid, you don't believe it is and you
>>> use EVM.
>>
>> When IMA metadata happens to be stored in local filesystems in
>> a trusted xattr, it's going to enjoy the protection you describe
>> without needing the addition of a cryptographic signature.
>>
>> However, that metadata doesn't live its whole life there. It
>> can reside in a tar file, it can cross a network, it can live
>> on a back-up tape. I think we agree that any time that metadata
>> is in transit or at rest outside of a Linux local filesystem, it
>> is exposed.
>>
>> Thus I'm interested in a metadata protection mechanism that does
>> not rely on the security characteristics of a particular storage
>> container. For me, a cryptographic signature fits that bill
>> nicely.
>
> Sure, but one of the points about IMA is a separation of mechanism from
> policy. Signed hashes (called appraisal in IMA terms) is just one
> policy you can decide to require or not or even make it conditional on
> other things.
AFAICT, the current EVM_IMA_DIGSIG and EVM_PORTABLE_DIGSIG formats are
always signed. The policy choice is whether or not to verify the
signature, not whether or not the metadata format is signed.
--
Chuck Lever
chucklever@gmail.com
WARNING: multiple messages have this Message-ID (diff)
From: Chuck Lever <chucklever@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: snitzer@redhat.com,
Deven Bowers <deven.desai@linux.microsoft.com>,
Mimi Zohar <zohar@linux.ibm.com>,
dm-devel@redhat.com, tyhicks@linux.microsoft.com,
Pavel Machek <pavel@ucw.cz>,
agk@redhat.com, Sasha Levin <sashal@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
James Morris <jmorris@namei.org>,
nramas@linux.microsoft.com, serge@hallyn.com,
pasha.tatashin@soleen.com, Jann Horn <jannh@google.com>,
linux-block@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
Jens Axboe <axboe@kernel.dk>,
mdsakib@microsoft.com, open list <linux-kernel@vger.kernel.org>,
linux-security-module@vger.kernel.org, linux-audit@redhat.com,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-integrity@vger.kernel.org,
jaskarankhurana@linux.microsoft.com
Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)
Date: Thu, 13 Aug 2020 10:56:17 -0400 [thread overview]
Message-ID: <49A45475-20D8-456E-92AD-F63DBC71F900@gmail.com> (raw)
In-Reply-To: <1597329763.3708.13.camel@HansenPartnership.com>
> On Aug 13, 2020, at 10:42 AM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> On Thu, 2020-08-13 at 10:21 -0400, Chuck Lever wrote:
>>> On Aug 12, 2020, at 11:42 AM, James Bottomley <James.Bottomley@Hans
>>> enPartnership.com> wrote:
> [...]
>>> For most people the security mechanism of local xattrs is
>>> sufficient. If you're paranoid, you don't believe it is and you
>>> use EVM.
>>
>> When IMA metadata happens to be stored in local filesystems in
>> a trusted xattr, it's going to enjoy the protection you describe
>> without needing the addition of a cryptographic signature.
>>
>> However, that metadata doesn't live its whole life there. It
>> can reside in a tar file, it can cross a network, it can live
>> on a back-up tape. I think we agree that any time that metadata
>> is in transit or at rest outside of a Linux local filesystem, it
>> is exposed.
>>
>> Thus I'm interested in a metadata protection mechanism that does
>> not rely on the security characteristics of a particular storage
>> container. For me, a cryptographic signature fits that bill
>> nicely.
>
> Sure, but one of the points about IMA is a separation of mechanism from
> policy. Signed hashes (called appraisal in IMA terms) is just one
> policy you can decide to require or not or even make it conditional on
> other things.
AFAICT, the current EVM_IMA_DIGSIG and EVM_PORTABLE_DIGSIG formats are
always signed. The policy choice is whether or not to verify the
signature, not whether or not the metadata format is signed.
--
Chuck Lever
chucklever@gmail.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
WARNING: multiple messages have this Message-ID (diff)
From: Chuck Lever <chucklever@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
James Morris <jmorris@namei.org>,
Deven Bowers <deven.desai@linux.microsoft.com>,
Pavel Machek <pavel@ucw.cz>, Sasha Levin <sashal@kernel.org>,
snitzer@redhat.com, dm-devel@redhat.com,
tyhicks@linux.microsoft.com, agk@redhat.com,
Paul Moore <paul@paul-moore.com>,
Jonathan Corbet <corbet@lwn.net>,
nramas@linux.microsoft.com, serge@hallyn.com,
pasha.tatashin@soleen.com, Jann Horn <jannh@google.com>,
linux-block@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
Jens Axboe <axboe@kernel.dk>,
mdsakib@microsoft.com, open list <linux-kernel@vger.kernel.org>,
eparis@redhat.com, linux-security-module@vger.kernel.org,
linux-audit@redhat.com,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-integrity@vger.kernel.org, jaskarankhurana@linu
Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)
Date: Thu, 13 Aug 2020 10:56:17 -0400 [thread overview]
Message-ID: <49A45475-20D8-456E-92AD-F63DBC71F900@gmail.com> (raw)
In-Reply-To: <1597329763.3708.13.camel@HansenPartnership.com>
> On Aug 13, 2020, at 10:42 AM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> On Thu, 2020-08-13 at 10:21 -0400, Chuck Lever wrote:
>>> On Aug 12, 2020, at 11:42 AM, James Bottomley <James.Bottomley@Hans
>>> enPartnership.com> wrote:
> [...]
>>> For most people the security mechanism of local xattrs is
>>> sufficient. If you're paranoid, you don't believe it is and you
>>> use EVM.
>>
>> When IMA metadata happens to be stored in local filesystems in
>> a trusted xattr, it's going to enjoy the protection you describe
>> without needing the addition of a cryptographic signature.
>>
>> However, that metadata doesn't live its whole life there. It
>> can reside in a tar file, it can cross a network, it can live
>> on a back-up tape. I think we agree that any time that metadata
>> is in transit or at rest outside of a Linux local filesystem, it
>> is exposed.
>>
>> Thus I'm interested in a metadata protection mechanism that does
>> not rely on the security characteristics of a particular storage
>> container. For me, a cryptographic signature fits that bill
>> nicely.
>
> Sure, but one of the points about IMA is a separation of mechanism from
> policy. Signed hashes (called appraisal in IMA terms) is just one
> policy you can decide to require or not or even make it conditional on
> other things.
AFAICT, the current EVM_IMA_DIGSIG and EVM_PORTABLE_DIGSIG formats are
always signed. The policy choice is whether or not to verify the
signature, not whether or not the metadata format is signed.
--
Chuck Lever
chucklever@gmail.com
next prev parent reply other threads:[~2020-08-13 14:56 UTC|newest]
Thread overview: 147+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 21:36 [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 01/11] scripts: add ipe tooling to generate boot policy Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 02/11] security: add ipe lsm evaluation loop and audit system Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 03/11] security: add ipe lsm policy parser and policy loading Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 04/11] ipe: add property for trust of boot volume Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 05/11] fs: add security blob and hooks for block_device Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 22:22 ` Casey Schaufler
2020-07-28 22:22 ` Casey Schaufler
2020-07-28 22:40 ` Al Viro
2020-07-28 22:40 ` Al Viro
2020-07-28 23:55 ` Deven Bowers
2020-07-28 23:55 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 06/11] dm-verity: move signature check after tree validation Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:50 ` Eric Biggers
2020-07-28 21:50 ` Eric Biggers
2020-07-28 23:55 ` Deven Bowers
2020-07-28 23:55 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 07/11] dm-verity: add bdev_setsecurity hook for dm-verity signature Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 08/11] ipe: add property for signed dmverity volumes Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 09/11] dm-verity: add bdev_setsecurity hook for root-hash Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 10/11] documentation: add ipe documentation Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 10/12] ipe: add property for dmverity roothash Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 11/11] cleanup: uapi/linux/audit.h Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 11/12] documentation: add ipe documentation Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-07-28 21:36 ` [RFC PATCH v5 12/12] cleanup: uapi/linux/audit.h Deven Bowers
2020-07-28 21:36 ` Deven Bowers
2020-08-02 11:55 ` [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) Pavel Machek
2020-08-02 11:55 ` Pavel Machek
2020-08-02 14:03 ` Sasha Levin
2020-08-02 14:03 ` Sasha Levin
2020-08-02 14:31 ` Pavel Machek
2020-08-02 14:31 ` Pavel Machek
2020-08-02 16:43 ` [dm-devel] " James Bottomley
2020-08-02 16:43 ` James Bottomley
2020-08-04 16:07 ` Deven Bowers
2020-08-04 16:07 ` Deven Bowers
2020-08-04 16:07 ` [dm-devel] " Deven Bowers
2020-08-05 15:01 ` James Bottomley
2020-08-05 15:01 ` James Bottomley
2020-08-05 15:01 ` [dm-devel] " James Bottomley
2020-08-05 16:59 ` James Morris
2020-08-05 16:59 ` James Morris
2020-08-05 18:15 ` Mimi Zohar
2020-08-05 18:15 ` Mimi Zohar
2020-08-05 23:51 ` James Morris
2020-08-05 23:51 ` James Morris
2020-08-06 14:33 ` Mimi Zohar
2020-08-06 14:33 ` Mimi Zohar
2020-08-06 14:33 ` Mimi Zohar
2020-08-07 16:41 ` James Morris
2020-08-07 16:41 ` James Morris
2020-08-07 17:31 ` Mimi Zohar
2020-08-07 17:31 ` Mimi Zohar
2020-08-07 18:40 ` Mimi Zohar
2020-08-07 18:40 ` Mimi Zohar
2020-08-10 20:29 ` James Morris
2020-08-10 20:29 ` James Morris
2020-08-08 17:47 ` Chuck Lever
2020-08-08 17:47 ` Chuck Lever
2020-08-09 17:16 ` Mimi Zohar
2020-08-09 17:16 ` Mimi Zohar
2020-08-10 15:35 ` James Bottomley
2020-08-10 15:35 ` James Bottomley
2020-08-10 16:35 ` Mimi Zohar
2020-08-10 16:35 ` Mimi Zohar
2020-08-10 17:13 ` James Bottomley
2020-08-10 17:13 ` James Bottomley
2020-08-10 17:57 ` Mimi Zohar
2020-08-10 17:57 ` Mimi Zohar
2020-08-10 23:36 ` Chuck Lever
2020-08-10 23:36 ` Chuck Lever
2020-08-10 23:36 ` Chuck Lever
2020-08-11 5:43 ` James Bottomley
2020-08-11 5:43 ` James Bottomley
2020-08-11 5:43 ` James Bottomley
2020-08-11 14:48 ` Chuck Lever
2020-08-11 14:48 ` Chuck Lever
2020-08-11 14:48 ` Chuck Lever
2020-08-11 15:32 ` James Bottomley
2020-08-11 15:32 ` James Bottomley
2020-08-11 15:32 ` James Bottomley
2020-08-11 19:30 ` Pavel Machek
2020-08-11 19:30 ` Pavel Machek
2020-08-11 19:30 ` Pavel Machek
2020-08-12 14:45 ` Chuck Lever
2020-08-12 14:45 ` Chuck Lever
2020-08-12 14:45 ` Chuck Lever
2020-08-11 15:53 ` James Bottomley
2020-08-11 15:53 ` James Bottomley
2020-08-11 15:53 ` James Bottomley
2020-08-12 14:15 ` Chuck Lever
2020-08-12 14:15 ` Chuck Lever
2020-08-12 14:15 ` Chuck Lever
2020-08-12 15:51 ` James Bottomley
2020-08-12 15:51 ` James Bottomley
2020-08-12 15:51 ` James Bottomley
2020-08-13 14:42 ` Chuck Lever
2020-08-13 14:42 ` Chuck Lever
2020-08-13 14:42 ` Chuck Lever
2020-08-13 15:10 ` James Bottomley
2020-08-13 15:10 ` James Bottomley
2020-08-13 15:10 ` James Bottomley
2020-08-14 14:21 ` Chuck Lever
2020-08-14 14:21 ` Chuck Lever
2020-08-14 14:21 ` Chuck Lever
2020-08-11 18:28 ` James Bottomley
2020-08-11 18:28 ` James Bottomley
2020-08-11 18:28 ` James Bottomley
2020-08-12 13:56 ` Chuck Lever
2020-08-12 13:56 ` Chuck Lever
2020-08-12 13:56 ` Chuck Lever
2020-08-12 15:42 ` James Bottomley
2020-08-12 15:42 ` James Bottomley
2020-08-12 15:42 ` James Bottomley
2020-08-13 14:21 ` Chuck Lever
2020-08-13 14:21 ` Chuck Lever
2020-08-13 14:21 ` Chuck Lever
2020-08-13 14:42 ` James Bottomley
2020-08-13 14:42 ` James Bottomley
2020-08-13 14:42 ` James Bottomley
2020-08-13 14:56 ` Chuck Lever [this message]
2020-08-13 14:56 ` Chuck Lever
2020-08-13 14:56 ` Chuck Lever
2020-08-11 21:03 ` James Morris
2020-08-11 21:03 ` James Morris
2020-08-11 21:03 ` James Morris
2020-08-12 14:18 ` Chuck Lever
2020-08-12 14:18 ` Chuck Lever
2020-08-12 14:18 ` Chuck Lever
2020-08-12 17:07 ` Deven Bowers
2020-08-12 17:07 ` 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=49A45475-20D8-456E-92AD-F63DBC71F900@gmail.com \
--to=chucklever@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--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=jannh@google.com \
--cc=jaskarankhurana@linux.microsoft.com \
--cc=jmorris@namei.org \
--cc=linux-audit@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mdsakib@microsoft.com \
--cc=nramas@linux.microsoft.com \
--cc=pasha.tatashin@soleen.com \
--cc=paul@paul-moore.com \
--cc=pavel@ucw.cz \
--cc=sashal@kernel.org \
--cc=serge@hallyn.com \
--cc=snitzer@redhat.com \
--cc=tyhicks@linux.microsoft.com \
--cc=viro@zeniv.linux.org.uk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.