From: James Morris <jmorris@namei.org>
To: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
linux-ima-devel@lists.sourceforge.net
Subject: Re: [Linux-ima-devel] [PATCH, RESEND 08/12] ima: added parser for RPM data type
Date: Wed, 02 Aug 2017 07:22:30 +0000 [thread overview]
Message-ID: <alpine.LRH.2.20.1708021716440.1117@namei.org> (raw)
In-Reply-To: <11206fd8-d189-deb0-ab67-aec373f8d979@huawei.com>
On Tue, 1 Aug 2017, Roberto Sassu wrote:
> On 8/1/2017 12:27 PM, Christoph Hellwig wrote:
> > On Tue, Aug 01, 2017 at 12:20:36PM +0200, Roberto Sassu wrote:
> > > This patch introduces a parser for RPM packages. It extracts the digests
> > > from the RPMTAG_FILEDIGESTS header section and converts them to binary
> > > data
> > > before adding them to the hash table.
> > >
> > > The advantage of this data type is that verifiers can determine who
> > > produced that data, as headers are signed by Linux distributions vendors.
> > > RPM headers signatures can be provided as digest list metadata.
> >
> > Err, parsing arbitrary file formats has no business in the kernel.
>
> The benefit of this choice is that no actions are required for
> Linux distribution vendors to support the solution I'm proposing,
> because they already provide signed digest lists (RPM headers).
>
> Since the proof of loading a digest list is the digest of the
> digest list (included in the list metadata), if RPM headers are
> converted to a different format, remote attestation verifiers
> cannot check the signature.
>
> If the concern is security, it would be possible to prevent unsigned
> RPM headers from being parsed, if the PGP key type is upstreamed
> (adding in CC keyrings@vger.kernel.org).
It's a security concern and also a layering violation, there should be no
need to parse package file formats in the kernel.
I'm not really clear on exactly how this patch series works. Can you
provide a more concrete explanation of what steps would occur during boot
and attestation?
--
James Morris
<jmorris@namei.org>
WARNING: multiple messages have this Message-ID (diff)
From: James Morris <jmorris@namei.org>
To: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
linux-ima-devel@lists.sourceforge.net
Subject: Re: [Linux-ima-devel] [PATCH, RESEND 08/12] ima: added parser for RPM data type
Date: Wed, 2 Aug 2017 17:22:30 +1000 (AEST) [thread overview]
Message-ID: <alpine.LRH.2.20.1708021716440.1117@namei.org> (raw)
In-Reply-To: <11206fd8-d189-deb0-ab67-aec373f8d979@huawei.com>
On Tue, 1 Aug 2017, Roberto Sassu wrote:
> On 8/1/2017 12:27 PM, Christoph Hellwig wrote:
> > On Tue, Aug 01, 2017 at 12:20:36PM +0200, Roberto Sassu wrote:
> > > This patch introduces a parser for RPM packages. It extracts the digests
> > > from the RPMTAG_FILEDIGESTS header section and converts them to binary
> > > data
> > > before adding them to the hash table.
> > >
> > > The advantage of this data type is that verifiers can determine who
> > > produced that data, as headers are signed by Linux distributions vendors.
> > > RPM headers signatures can be provided as digest list metadata.
> >
> > Err, parsing arbitrary file formats has no business in the kernel.
>
> The benefit of this choice is that no actions are required for
> Linux distribution vendors to support the solution I'm proposing,
> because they already provide signed digest lists (RPM headers).
>
> Since the proof of loading a digest list is the digest of the
> digest list (included in the list metadata), if RPM headers are
> converted to a different format, remote attestation verifiers
> cannot check the signature.
>
> If the concern is security, it would be possible to prevent unsigned
> RPM headers from being parsed, if the PGP key type is upstreamed
> (adding in CC keyrings@vger.kernel.org).
It's a security concern and also a layering violation, there should be no
need to parse package file formats in the kernel.
I'm not really clear on exactly how this patch series works. Can you
provide a more concrete explanation of what steps would occur during boot
and attestation?
--
James Morris
<jmorris@namei.org>
WARNING: multiple messages have this Message-ID (diff)
From: jmorris@namei.org (James Morris)
To: linux-security-module@vger.kernel.org
Subject: [Linux-ima-devel] [PATCH, RESEND 08/12] ima: added parser for RPM data type
Date: Wed, 2 Aug 2017 17:22:30 +1000 (AEST) [thread overview]
Message-ID: <alpine.LRH.2.20.1708021716440.1117@namei.org> (raw)
In-Reply-To: <11206fd8-d189-deb0-ab67-aec373f8d979@huawei.com>
On Tue, 1 Aug 2017, Roberto Sassu wrote:
> On 8/1/2017 12:27 PM, Christoph Hellwig wrote:
> > On Tue, Aug 01, 2017 at 12:20:36PM +0200, Roberto Sassu wrote:
> > > This patch introduces a parser for RPM packages. It extracts the digests
> > > from the RPMTAG_FILEDIGESTS header section and converts them to binary
> > > data
> > > before adding them to the hash table.
> > >
> > > The advantage of this data type is that verifiers can determine who
> > > produced that data, as headers are signed by Linux distributions vendors.
> > > RPM headers signatures can be provided as digest list metadata.
> >
> > Err, parsing arbitrary file formats has no business in the kernel.
>
> The benefit of this choice is that no actions are required for
> Linux distribution vendors to support the solution I'm proposing,
> because they already provide signed digest lists (RPM headers).
>
> Since the proof of loading a digest list is the digest of the
> digest list (included in the list metadata), if RPM headers are
> converted to a different format, remote attestation verifiers
> cannot check the signature.
>
> If the concern is security, it would be possible to prevent unsigned
> RPM headers from being parsed, if the PGP key type is upstreamed
> (adding in CC keyrings at vger.kernel.org).
It's a security concern and also a layering violation, there should be no
need to parse package file formats in the kernel.
I'm not really clear on exactly how this patch series works. Can you
provide a more concrete explanation of what steps would occur during boot
and attestation?
--
James Morris
<jmorris@namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-08-02 7:22 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 15:44 [PATCH 00/12] ima: measure digest lists instead of individual files Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 01/12] ima: generalize ima_read_policy() Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 02/12] ima: generalize ima_write_policy() Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 03/12] ima: generalize policy file operations Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 04/12] ima: use ima_show_htable_value to show hash table data Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 05/12] ima: add functions to manage digest lists Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 06/12] ima: added parser of digest lists metadata Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-27 5:15 ` kbuild test robot
2017-07-27 5:15 ` kbuild test robot
2017-08-01 10:17 ` [PATCH, RESEND " Roberto Sassu
2017-08-01 10:17 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 07/12] ima: added parser for compact digest list Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 08/12] ima: added parser for RPM data type Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-27 5:03 ` kbuild test robot
2017-07-27 5:03 ` kbuild test robot
2017-08-01 10:20 ` [PATCH, RESEND " Roberto Sassu
2017-08-01 10:20 ` Roberto Sassu
2017-08-01 10:27 ` Christoph Hellwig
2017-08-01 10:27 ` Christoph Hellwig
2017-08-01 10:58 ` Roberto Sassu
2017-08-01 10:58 ` Roberto Sassu
2017-08-01 10:58 ` Roberto Sassu
2017-08-02 7:22 ` James Morris [this message]
2017-08-02 7:22 ` [Linux-ima-devel] " James Morris
2017-08-02 7:22 ` James Morris
2017-08-02 11:22 ` Roberto Sassu
2017-08-02 11:22 ` Roberto Sassu
2017-08-02 11:22 ` Roberto Sassu
2017-08-09 9:15 ` Roberto Sassu
2017-08-09 9:15 ` Roberto Sassu
2017-08-09 9:15 ` Roberto Sassu
2017-08-09 14:30 ` Mimi Zohar
2017-08-09 14:30 ` Mimi Zohar
2017-08-09 14:30 ` Mimi Zohar
2017-08-09 17:18 ` Roberto Sassu
2017-08-09 17:18 ` Roberto Sassu
2017-08-09 17:18 ` Roberto Sassu
2017-08-10 13:12 ` Mimi Zohar
2017-08-10 13:12 ` Mimi Zohar
2017-08-10 13:12 ` Mimi Zohar
2017-08-17 9:15 ` Roberto Sassu
2017-08-17 9:15 ` Roberto Sassu
2017-08-17 9:15 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 09/12] ima: introduce securityfs interfaces for digest lists Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-27 5:38 ` kbuild test robot
2017-07-27 5:38 ` kbuild test robot
2017-07-25 15:44 ` [PATCH 10/12] ima: disable digest lookup if digest lists are not measured Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 11/12] ima: don't report measurements if digests are included in the loaded lists Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-08-09 20:36 ` [Linux-ima-devel] " Ken Goldman
2017-08-09 20:36 ` Ken Goldman
2017-08-17 8:32 ` Roberto Sassu
2017-08-17 8:32 ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 12/12] ima: added Documentation/security/IMA-digest-lists.txt Roberto Sassu
2017-07-25 15:44 ` Roberto Sassu
2017-12-05 22:28 ` [Linux-ima-devel] " Ken Goldman
2017-12-06 9:22 ` Roberto Sassu
2017-12-06 9:22 ` Roberto Sassu
2017-07-26 21:54 ` [PATCH 00/12] ima: measure digest lists instead of individual files Mimi Zohar
2017-07-26 21:54 ` Mimi Zohar
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=alpine.LRH.2.20.1708021716440.1117@namei.org \
--to=jmorris@namei.org \
--cc=hch@infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ima-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=roberto.sassu@huawei.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.