From: Roberto Sassu <roberto.sassu@huawei.com>
To: James Morris <jmorris@namei.org>
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 11:22:35 +0000 [thread overview]
Message-ID: <5de9c4a2-dc96-b916-162a-adafd7da278b@huawei.com> (raw)
In-Reply-To: <alpine.LRH.2.20.1708021716440.1117@namei.org>
On 8/2/2017 9:22 AM, James Morris wrote:
> 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?
The main idea of this patch set is that, if a system executes
or reads good files (e.g. those from a Linux distribution),
the difference between the assertion 'a file could have possibly
been accessed' and 'a file has been accessed' is not relevant
for verifiers that only check the provenance of software.
Then, for those verifiers, a measurement representing the list of
good files which could have possibly been accessed gives the same
guarantees of individual file measurements.
The patch set introduces two data types:
- digest list: contains the digests of good files
- list metadata: contains the digest, the signature and the path
of each digest list to load (why loading many
lists instead of one will be clear after I explain
the remote attestation verification process)
Steps at boot:
1) systemd reads the path of list metadata from /etc/ima/digest-lists
and writes it to a new securityfs file created by IMA
2) IMA reads and parses the list metadata (same mechanism for
loading a policy, already upstreamed)
3) for each list metadata, IMA reads and parses the digest list
and adds the file digests to a hash table
4) when a file is accessed, IMA calculates the digest as before
and searches the file digest in the new hash table; if the
digest is found, IMA sets the IMA_MEASURED flag in the inode
metadata and clears the IMA_MEASURE action
Notes:
- list metadata and digest lists are measured before IMA reads them
- the digest of digest lists is also added to the hash table, otherwise
there would be a measurement for each digest list
The measurement list looks like:
10 <template digest> ima-ng <digest> boot_aggregate
10 <template digest> ima-ng <digest> systemd (exe + libs)
10 <template digest> ima-ng <digest> /etc/ima/digest-lists
10 <template digest> ima-ng <digest> <list metadata>
10 <template digest> ima-ng <digest> <unknown files>
Steps during the verification:
Case 1: list metadata and digest lists are provided to verifiers
This is necessary when:
- digest lists are not signed
- verifiers do not trust the signer
- verifiers want to perform more checks on digest lists
(digest lists may contain digest of outdated software)
Verifiers:
1) parse the list metadata received
2) for each digest list received, calculate the digest and
compare it with the digest included in the list metadata
3) calculate the digest of list metadata and compare it with
the digest in the measurement list
4) calculate the digest of the path of list metadata and compare
it with the digest of /etc/ima/digest-lists in the measurement list
5) check boot_aggregate, systemd exe and libs, and unknown files
6) check the digest lists
Case 2: only list metadata is provided to verifiers
Verifiers:
1) parse the list metadata received
2) for each digest list, verify the signature
3) calculate the digest of the path of list metadata and compare
it with the digest of /etc/ima/digest-lists in the measurement list
4) check boot_aggregate, systemd exe and libs, and unknown files
In Case 2, the verification process is simplified, because if
the signature of digest lists is valid, this means that possibly
accessed files are provided by the signer.
The problem here is that verifiers know the digest of possibly
accessed files from the measurement done by IMA at the time
digest lists are read. If IMA cannot parse the original (signed)
digest list, it would measure something that cannot be verified
with the signature.
RPM-based distributions already provide signed digest lists
(the RPM headers) for each package. To avoid the performance
penalty due to extending a PCR for each digest list, only
an entry for the list metadata is added to the measurement list.
For RPM-based Linux distributions, the full lifecycle for configuring
IMA can be implemented with very low effort. The tasks are:
1) systemd patch to load list metadata: just extend the existing
patch to load the policy
2) userspace tools to parse the RPM database: done
3) dracut module to generate and include the digest lists and
metadata into the initial ram disk: at the moment this is done
from the dracut command line
4) plugin for the software management that executes the tool
to generate the digest list for updated packages: to be implemented
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
WARNING: multiple messages have this Message-ID (diff)
From: Roberto Sassu <roberto.sassu@huawei.com>
To: James Morris <jmorris@namei.org>
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 13:22:35 +0200 [thread overview]
Message-ID: <5de9c4a2-dc96-b916-162a-adafd7da278b@huawei.com> (raw)
In-Reply-To: <alpine.LRH.2.20.1708021716440.1117@namei.org>
On 8/2/2017 9:22 AM, James Morris wrote:
> 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?
The main idea of this patch set is that, if a system executes
or reads good files (e.g. those from a Linux distribution),
the difference between the assertion 'a file could have possibly
been accessed' and 'a file has been accessed' is not relevant
for verifiers that only check the provenance of software.
Then, for those verifiers, a measurement representing the list of
good files which could have possibly been accessed gives the same
guarantees of individual file measurements.
The patch set introduces two data types:
- digest list: contains the digests of good files
- list metadata: contains the digest, the signature and the path
of each digest list to load (why loading many
lists instead of one will be clear after I explain
the remote attestation verification process)
Steps at boot:
1) systemd reads the path of list metadata from /etc/ima/digest-lists
and writes it to a new securityfs file created by IMA
2) IMA reads and parses the list metadata (same mechanism for
loading a policy, already upstreamed)
3) for each list metadata, IMA reads and parses the digest list
and adds the file digests to a hash table
4) when a file is accessed, IMA calculates the digest as before
and searches the file digest in the new hash table; if the
digest is found, IMA sets the IMA_MEASURED flag in the inode
metadata and clears the IMA_MEASURE action
Notes:
- list metadata and digest lists are measured before IMA reads them
- the digest of digest lists is also added to the hash table, otherwise
there would be a measurement for each digest list
The measurement list looks like:
10 <template digest> ima-ng <digest> boot_aggregate
10 <template digest> ima-ng <digest> systemd (exe + libs)
10 <template digest> ima-ng <digest> /etc/ima/digest-lists
10 <template digest> ima-ng <digest> <list metadata>
10 <template digest> ima-ng <digest> <unknown files>
Steps during the verification:
Case 1: list metadata and digest lists are provided to verifiers
This is necessary when:
- digest lists are not signed
- verifiers do not trust the signer
- verifiers want to perform more checks on digest lists
(digest lists may contain digest of outdated software)
Verifiers:
1) parse the list metadata received
2) for each digest list received, calculate the digest and
compare it with the digest included in the list metadata
3) calculate the digest of list metadata and compare it with
the digest in the measurement list
4) calculate the digest of the path of list metadata and compare
it with the digest of /etc/ima/digest-lists in the measurement list
5) check boot_aggregate, systemd exe and libs, and unknown files
6) check the digest lists
Case 2: only list metadata is provided to verifiers
Verifiers:
1) parse the list metadata received
2) for each digest list, verify the signature
3) calculate the digest of the path of list metadata and compare
it with the digest of /etc/ima/digest-lists in the measurement list
4) check boot_aggregate, systemd exe and libs, and unknown files
In Case 2, the verification process is simplified, because if
the signature of digest lists is valid, this means that possibly
accessed files are provided by the signer.
The problem here is that verifiers know the digest of possibly
accessed files from the measurement done by IMA at the time
digest lists are read. If IMA cannot parse the original (signed)
digest list, it would measure something that cannot be verified
with the signature.
RPM-based distributions already provide signed digest lists
(the RPM headers) for each package. To avoid the performance
penalty due to extending a PCR for each digest list, only
an entry for the list metadata is added to the measurement list.
For RPM-based Linux distributions, the full lifecycle for configuring
IMA can be implemented with very low effort. The tasks are:
1) systemd patch to load list metadata: just extend the existing
patch to load the policy
2) userspace tools to parse the RPM database: done
3) dracut module to generate and include the digest lists and
metadata into the initial ram disk: at the moment this is done
from the dracut command line
4) plugin for the software management that executes the tool
to generate the digest list for updated packages: to be implemented
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
WARNING: multiple messages have this Message-ID (diff)
From: roberto.sassu@huawei.com (Roberto Sassu)
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 13:22:35 +0200 [thread overview]
Message-ID: <5de9c4a2-dc96-b916-162a-adafd7da278b@huawei.com> (raw)
In-Reply-To: <alpine.LRH.2.20.1708021716440.1117@namei.org>
On 8/2/2017 9:22 AM, James Morris wrote:
> 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?
The main idea of this patch set is that, if a system executes
or reads good files (e.g. those from a Linux distribution),
the difference between the assertion 'a file could have possibly
been accessed' and 'a file has been accessed' is not relevant
for verifiers that only check the provenance of software.
Then, for those verifiers, a measurement representing the list of
good files which could have possibly been accessed gives the same
guarantees of individual file measurements.
The patch set introduces two data types:
- digest list: contains the digests of good files
- list metadata: contains the digest, the signature and the path
of each digest list to load (why loading many
lists instead of one will be clear after I explain
the remote attestation verification process)
Steps at boot:
1) systemd reads the path of list metadata from /etc/ima/digest-lists
and writes it to a new securityfs file created by IMA
2) IMA reads and parses the list metadata (same mechanism for
loading a policy, already upstreamed)
3) for each list metadata, IMA reads and parses the digest list
and adds the file digests to a hash table
4) when a file is accessed, IMA calculates the digest as before
and searches the file digest in the new hash table; if the
digest is found, IMA sets the IMA_MEASURED flag in the inode
metadata and clears the IMA_MEASURE action
Notes:
- list metadata and digest lists are measured before IMA reads them
- the digest of digest lists is also added to the hash table, otherwise
there would be a measurement for each digest list
The measurement list looks like:
10 <template digest> ima-ng <digest> boot_aggregate
10 <template digest> ima-ng <digest> systemd (exe + libs)
10 <template digest> ima-ng <digest> /etc/ima/digest-lists
10 <template digest> ima-ng <digest> <list metadata>
10 <template digest> ima-ng <digest> <unknown files>
Steps during the verification:
Case 1: list metadata and digest lists are provided to verifiers
This is necessary when:
- digest lists are not signed
- verifiers do not trust the signer
- verifiers want to perform more checks on digest lists
(digest lists may contain digest of outdated software)
Verifiers:
1) parse the list metadata received
2) for each digest list received, calculate the digest and
compare it with the digest included in the list metadata
3) calculate the digest of list metadata and compare it with
the digest in the measurement list
4) calculate the digest of the path of list metadata and compare
it with the digest of /etc/ima/digest-lists in the measurement list
5) check boot_aggregate, systemd exe and libs, and unknown files
6) check the digest lists
Case 2: only list metadata is provided to verifiers
Verifiers:
1) parse the list metadata received
2) for each digest list, verify the signature
3) calculate the digest of the path of list metadata and compare
it with the digest of /etc/ima/digest-lists in the measurement list
4) check boot_aggregate, systemd exe and libs, and unknown files
In Case 2, the verification process is simplified, because if
the signature of digest lists is valid, this means that possibly
accessed files are provided by the signer.
The problem here is that verifiers know the digest of possibly
accessed files from the measurement done by IMA at the time
digest lists are read. If IMA cannot parse the original (signed)
digest list, it would measure something that cannot be verified
with the signature.
RPM-based distributions already provide signed digest lists
(the RPM headers) for each package. To avoid the performance
penalty due to extending a PCR for each digest list, only
an entry for the list metadata is added to the measurement list.
For RPM-based Linux distributions, the full lifecycle for configuring
IMA can be implemented with very low effort. The tasks are:
1) systemd patch to load list metadata: just extend the existing
patch to load the policy
2) userspace tools to parse the RPM database: done
3) dracut module to generate and include the digest lists and
metadata into the initial ram disk: at the moment this is done
from the dracut command line
4) plugin for the software management that executes the tool
to generate the digest list for updated packages: to be implemented
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
--
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 11: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 ` [Linux-ima-devel] " James Morris
2017-08-02 7:22 ` James Morris
2017-08-02 7:22 ` James Morris
2017-08-02 11:22 ` Roberto Sassu [this message]
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=5de9c4a2-dc96-b916-162a-adafd7da278b@huawei.com \
--to=roberto.sassu@huawei.com \
--cc=hch@infradead.org \
--cc=jmorris@namei.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 \
/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.