From: Roberto Sassu <roberto.sassu@huawei.com> To: Matthew Garrett <mjg59@google.com> Cc: linux-integrity <linux-integrity@vger.kernel.org>, <linux-security-module@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <silviu.vlasceanu@huawei.com> Subject: Re: [PATCH v2 00/15] ima: digest list feature Date: Thu, 9 Nov 2017 10:51:15 +0100 [thread overview] Message-ID: <210975fe-527c-df2f-5a8a-9aca31e9246a@huawei.com> (raw) In-Reply-To: <CACdnJut0-4k97m0TM-Zd4jLPTraBe6_JoE-eznFYKwbPEmNS0Q@mail.gmail.com> On 11/8/2017 4:48 PM, Matthew Garrett wrote: > On Wed, Nov 8, 2017 at 7:00 AM, Roberto Sassu <roberto.sassu@huawei.com> wrote: >> On 11/7/2017 7:06 PM, Matthew Garrett wrote: >>> But we're still left in a state where the kernel has to end up >>> supporting a number of very niche formats, and userland agility is >>> tied to the kernel. I think it makes significantly more sense to push >>> the problem out to userland. >> >> >> At least for appraisal, digest lists must be parsed by the kernel. If >> the parser is moved to userspace, I don't know if we are able to provide >> the same guarantee, that the correct set of digests has been uploaded to >> IMA. A new measurement can be added, when IMA receives the digests, but >> a verifier has to verify the signature of the original file, perform >> format conversion, calculate the digest and compare it with that in the >> new IMA measurement. If digest lists are parsed directly by the kernel, >> then the signature can be verified directly. > > The code doing the parsing is in the initramfs, which has already been > measured at boot time. You can guarantee that it's being done by > trusted code. The parser can be executed in the initial ram disk, but everything accessed before the parser is executed will be measured/appraised without digest lists. To do signature-based remote attestation, where the verification consists on checking the signature of digests of measured files, it would be necessary to sign systemd, libraries, everything accessed before the parser, and the parser. If RPM headers are parsed by the kernel, measurement/appraisal will be done directly with digest lists. >>> Isn't failing to upload the expected digest list just a DoS? We >>> already expect to load keys from initramfs, so it seems fine to parse >>> stuff there - what's the problem with extracting information from >>> RPMs, translating them to the generic format and pushing that into the >>> kernel? >> >> >> The main problem is that the digest list measurement, performed when the >> parser accesses the file containing the RPM header, might not reflect >> what IMA uses for digest lookup. > > Why not? I assumed you wanted to measure digest lists only at the time they are read by the parser, and not when they are read by IMA. If instead digest lists are verified again after conversion, the new workflow should be: 1) the kernel parses digest list metadata before systemd is executed 2) the kernel verifies the signature of digest lists (RPM headers) and add the digest of digest lists to the hash table, so that appraisal succeeds 3) systemd (with file signature) is executed 4) the parser (with file signature) is executed 5) the parser reads and converts the digest lists to the generic format, and writes them to a tmpfs filesystem 6) the parser generates a new digest list metadata file with the path of converted digest lists and sends the path of the new metadata to IMA 7) IMA reads the generic digest lists The measurement list should look like: 10 <digest> ima-sig <digest> boot_aggregate 10 <digest> ima-sig <digest> /etc/ima/digest_lists/metadata 10 <digest> ima-sig <digest> /usr/lib/systemd/systemd <signature> ... 10 <digest> ima-sig <digest> <parser> <signature> 10 <digest> ima-sig <digest> /tmp/metadata If parsing of RPM headers is done by the kernel, the measurement list will look like: 10 <digest> ima-ng <digest> boot_aggregate 10 <digest> ima-ng <digest> /etc/ima/digest_lists/metadata A built-in policy should enable appraisal of tmpfs. If not, patch 11/15 disables digest lookup for appraisal. Since generic digest lists will have a security.ima extended attribute (they are mutable files), appraisal verification will succeed. With this solution, digital signatures cannot be required, because generic digest lists will have a HMAC. For appraisal, it becomes necessary to ensure that only digest lists written by the parser can be processed by IMA. 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: [PATCH v2 00/15] ima: digest list feature Date: Thu, 9 Nov 2017 10:51:15 +0100 [thread overview] Message-ID: <210975fe-527c-df2f-5a8a-9aca31e9246a@huawei.com> (raw) In-Reply-To: <CACdnJut0-4k97m0TM-Zd4jLPTraBe6_JoE-eznFYKwbPEmNS0Q@mail.gmail.com> On 11/8/2017 4:48 PM, Matthew Garrett wrote: > On Wed, Nov 8, 2017 at 7:00 AM, Roberto Sassu <roberto.sassu@huawei.com> wrote: >> On 11/7/2017 7:06 PM, Matthew Garrett wrote: >>> But we're still left in a state where the kernel has to end up >>> supporting a number of very niche formats, and userland agility is >>> tied to the kernel. I think it makes significantly more sense to push >>> the problem out to userland. >> >> >> At least for appraisal, digest lists must be parsed by the kernel. If >> the parser is moved to userspace, I don't know if we are able to provide >> the same guarantee, that the correct set of digests has been uploaded to >> IMA. A new measurement can be added, when IMA receives the digests, but >> a verifier has to verify the signature of the original file, perform >> format conversion, calculate the digest and compare it with that in the >> new IMA measurement. If digest lists are parsed directly by the kernel, >> then the signature can be verified directly. > > The code doing the parsing is in the initramfs, which has already been > measured at boot time. You can guarantee that it's being done by > trusted code. The parser can be executed in the initial ram disk, but everything accessed before the parser is executed will be measured/appraised without digest lists. To do signature-based remote attestation, where the verification consists on checking the signature of digests of measured files, it would be necessary to sign systemd, libraries, everything accessed before the parser, and the parser. If RPM headers are parsed by the kernel, measurement/appraisal will be done directly with digest lists. >>> Isn't failing to upload the expected digest list just a DoS? We >>> already expect to load keys from initramfs, so it seems fine to parse >>> stuff there - what's the problem with extracting information from >>> RPMs, translating them to the generic format and pushing that into the >>> kernel? >> >> >> The main problem is that the digest list measurement, performed when the >> parser accesses the file containing the RPM header, might not reflect >> what IMA uses for digest lookup. > > Why not? I assumed you wanted to measure digest lists only at the time they are read by the parser, and not when they are read by IMA. If instead digest lists are verified again after conversion, the new workflow should be: 1) the kernel parses digest list metadata before systemd is executed 2) the kernel verifies the signature of digest lists (RPM headers) and add the digest of digest lists to the hash table, so that appraisal succeeds 3) systemd (with file signature) is executed 4) the parser (with file signature) is executed 5) the parser reads and converts the digest lists to the generic format, and writes them to a tmpfs filesystem 6) the parser generates a new digest list metadata file with the path of converted digest lists and sends the path of the new metadata to IMA 7) IMA reads the generic digest lists The measurement list should look like: 10 <digest> ima-sig <digest> boot_aggregate 10 <digest> ima-sig <digest> /etc/ima/digest_lists/metadata 10 <digest> ima-sig <digest> /usr/lib/systemd/systemd <signature> ... 10 <digest> ima-sig <digest> <parser> <signature> 10 <digest> ima-sig <digest> /tmp/metadata If parsing of RPM headers is done by the kernel, the measurement list will look like: 10 <digest> ima-ng <digest> boot_aggregate 10 <digest> ima-ng <digest> /etc/ima/digest_lists/metadata A built-in policy should enable appraisal of tmpfs. If not, patch 11/15 disables digest lookup for appraisal. Since generic digest lists will have a security.ima extended attribute (they are mutable files), appraisal verification will succeed. With this solution, digital signatures cannot be required, because generic digest lists will have a HMAC. For appraisal, it becomes necessary to ensure that only digest lists written by the parser can be processed by IMA. 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-11-09 9:51 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-07 10:36 [PATCH v2 00/15] ima: digest list feature Roberto Sassu 2017-11-07 10:36 ` Roberto Sassu 2017-11-07 10:36 ` [PATCH v2 01/15] ima: generalize ima_read_policy() Roberto Sassu 2017-11-07 10:36 ` Roberto Sassu 2017-11-07 10:36 ` [PATCH v2 02/15] ima: generalize ima_write_policy() Roberto Sassu 2017-11-07 10:36 ` Roberto Sassu 2017-11-07 10:36 ` [PATCH v2 03/15] ima: generalize policy file operations Roberto Sassu 2017-11-07 10:36 ` Roberto Sassu 2017-11-07 10:36 ` [PATCH v2 04/15] ima: use ima_show_htable_value to show hash table data Roberto Sassu 2017-11-07 10:36 ` Roberto Sassu 2017-11-07 10:37 ` [PATCH v2 05/15] ima: add functions to manage digest lists Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-07 10:37 ` [PATCH v2 06/15] ima: add parser of digest lists metadata Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-18 4:20 ` Serge E. Hallyn 2017-11-18 4:20 ` Serge E. Hallyn 2017-11-18 23:23 ` Mimi Zohar 2017-11-18 23:23 ` Mimi Zohar 2017-11-20 9:40 ` Roberto Sassu 2017-11-20 9:40 ` Roberto Sassu 2017-11-20 13:53 ` Mimi Zohar 2017-11-20 13:53 ` Mimi Zohar 2017-11-20 13:53 ` Mimi Zohar 2017-11-20 16:52 ` Serge E. Hallyn 2017-11-20 16:52 ` Serge E. Hallyn 2017-11-20 16:52 ` Serge E. Hallyn 2017-11-20 16:52 ` Serge E. Hallyn 2017-11-07 10:37 ` [PATCH v2 07/15] ima: add parser of compact digest list Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-07 10:37 ` [PATCH v2 08/15] ima: add parser of RPM package headers Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-07 10:37 ` [PATCH v2 09/15] ima: introduce securityfs interfaces for digest lists Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-07 10:37 ` [PATCH v2 10/15] ima: disable digest lookup if digest lists are not checked Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-07 10:37 ` [PATCH v2 11/15] ima: add policy action digest_list Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-07 10:37 ` [PATCH v2 12/15] ima: do not update security.ima if appraisal status is not INTEGRITY_PASS Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-18 4:25 ` Serge E. Hallyn 2017-11-18 4:25 ` Serge E. Hallyn 2017-11-07 10:37 ` [PATCH v2 13/15] evm: add kernel command line option to select protected xattrs Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-07 10:37 ` [PATCH v2 14/15] ima: add support for appraisal with digest lists Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-07 10:37 ` [PATCH v2 15/15] ima: add Documentation/security/IMA-digest-lists.txt Roberto Sassu 2017-11-07 10:37 ` Roberto Sassu 2017-11-07 13:37 ` [PATCH v2 00/15] ima: digest list feature Mimi Zohar 2017-11-07 13:37 ` Mimi Zohar 2017-11-07 13:37 ` Mimi Zohar 2017-11-07 16:45 ` Roberto Sassu 2017-11-07 16:45 ` Roberto Sassu 2017-11-07 16:45 ` Roberto Sassu 2017-11-17 1:08 ` Kees Cook 2017-11-17 1:08 ` Kees Cook 2017-11-17 8:55 ` Roberto Sassu 2017-11-17 8:55 ` Roberto Sassu 2017-11-17 12:21 ` Mimi Zohar 2017-11-17 12:21 ` Mimi Zohar 2017-11-17 12:21 ` Mimi Zohar 2017-11-07 14:49 ` Matthew Garrett 2017-11-07 14:49 ` Matthew Garrett 2017-11-07 17:53 ` Roberto Sassu 2017-11-07 17:53 ` Roberto Sassu 2017-11-07 18:06 ` Matthew Garrett 2017-11-07 18:06 ` Matthew Garrett 2017-11-08 12:00 ` Roberto Sassu 2017-11-08 12:00 ` Roberto Sassu 2017-11-08 15:48 ` Matthew Garrett 2017-11-08 15:48 ` Matthew Garrett 2017-11-09 9:51 ` Roberto Sassu [this message] 2017-11-09 9:51 ` Roberto Sassu 2017-11-09 14:47 ` Matthew Garrett 2017-11-09 14:47 ` Matthew Garrett 2017-11-09 16:13 ` Roberto Sassu 2017-11-09 16:13 ` Roberto Sassu 2017-11-09 16:46 ` Matthew Garrett 2017-11-09 16:46 ` Matthew Garrett 2017-11-09 17:23 ` Roberto Sassu 2017-11-09 17:23 ` Roberto Sassu 2017-11-09 16:17 ` Mimi Zohar 2017-11-09 16:17 ` Mimi Zohar 2017-11-09 16:17 ` Mimi Zohar 2017-11-07 18:03 ` Safford, David (GE Global Research, US) 2017-11-07 18:03 ` Safford, David (GE Global Research, US) 2017-11-07 18:03 ` Safford, David (GE Global Research, US) 2017-11-08 10:16 ` Roberto Sassu 2017-11-08 10:16 ` Roberto Sassu 2017-11-08 10:16 ` Roberto Sassu 2017-12-05 22:03 ` Ken Goldman 2017-12-05 22:03 ` Ken Goldman 2017-12-06 9:13 ` Roberto Sassu 2017-12-06 9:13 ` Roberto Sassu 2017-12-08 21:59 ` Ken Goldman 2017-12-11 8:26 ` Roberto Sassu 2017-12-22 15:56 ` Ken Goldman
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=210975fe-527c-df2f-5a8a-9aca31e9246a@huawei.com \ --to=roberto.sassu@huawei.com \ --cc=linux-doc@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=mjg59@google.com \ --cc=silviu.vlasceanu@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: linkBe 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.