Re: [PATCH v2 06/15] ima: add parser of digest lists metadata
On Tue, Nov 07, 2017 at 11:37:01AM +0100, Roberto Sassu wrote: > from a predefined position (/etc/ima/digest_lists/metadata), when rootfs > becomes available. Digest lists must be loaded before IMA appraisal is in > enforcing mode. I'm sure there's a good reason for it, but this seems weird to me. Why read it from a file on disk instead of accepting it through say a securityfile write?
Re: [PATCH v2 06/15] ima: add parser of digest lists metadata
Hi Serge, On Fri, 2017-11-17 at 22:20 -0600, Serge E. Hallyn wrote: > On Tue, Nov 07, 2017 at 11:37:01AM +0100, Roberto Sassu wrote: > > from a predefined position (/etc/ima/digest_lists/metadata), when rootfs > > becomes available. Digest lists must be loaded before IMA appraisal is in > > enforcing mode. > > I'm sure there's a good reason for it, but this seems weird to me. > Why read it from a file on disk instead of accepting it through say > a securityfile write? Assuming that the concept of a white list is something we want to support, then at minimum the list needs to be signed and verified. Instead of defining a new Kconfig pathname option, a securityfs file could read it, like the IMA policy. Mimi
Re: [PATCH v2 06/15] ima: add parser of digest lists metadata
On 11/19/2017 12:23 AM, Mimi Zohar wrote: Hi Serge, On Fri, 2017-11-17 at 22:20 -0600, Serge E. Hallyn wrote: On Tue, Nov 07, 2017 at 11:37:01AM +0100, Roberto Sassu wrote: from a predefined position (/etc/ima/digest_lists/metadata), when rootfs becomes available. Digest lists must be loaded before IMA appraisal is in enforcing mode. I'm sure there's a good reason for it, but this seems weird to me. Why read it from a file on disk instead of accepting it through say a securityfile write? There are two reasons. Digest lists must be loaded before any file is accessed, otherwise IMA will deny the operation if appraisal is in enforcing mode. With digest lists it is possible to appraise files in the initial ram disk without including extended attributes (the default policy excludes those files). The second reason is that appraisal has to be temporarily disabled because the file containing digest list metadata is not signed. The same happens when loading a public key (check ima_load_x509() in ima_init.c). The file containing digest list metadata is not signed because its content depends on the list of installed packages. I thought it is acceptable to load it without verification, as providing the path of digest lists is similar to writing the path of a policy to a securityfs file. The important point is that no digest is added to the hash table without verifying the signature first. The alternative would be to load signed digest lists directly. But, the main issue is that there would be a PCR extend for each digest list, while with digest list metadata there is only one. Assuming that the concept of a white list is something we want to support, then at minimum the list needs to be signed and verified. Instead of defining a new Kconfig pathname option, a securityfs file could read it, like the IMA policy. Both methods are supported (patch 9/15 introduces 'digest_lists' in the securityfs filesystem). The securityfs file can be used to load digest lists for files not in the initial ram disk, and for system updates. Roberto -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
Re: [PATCH v2 06/15] ima: add parser of digest lists metadata
On Mon, 2017-11-20 at 10:40 +0100, Roberto Sassu wrote: > On 11/19/2017 12:23 AM, Mimi Zohar wrote: > > Hi Serge, > > > > On Fri, 2017-11-17 at 22:20 -0600, Serge E. Hallyn wrote: > >> On Tue, Nov 07, 2017 at 11:37:01AM +0100, Roberto Sassu wrote: > >>> from a predefined position (/etc/ima/digest_lists/metadata), when rootfs > >>> becomes available. Digest lists must be loaded before IMA appraisal is in > >>> enforcing mode. > >> > >> I'm sure there's a good reason for it, but this seems weird to me. > >> Why read it from a file on disk instead of accepting it through say > >> a securityfile write? > > There are two reasons. > > Digest lists must be loaded before any file is accessed, otherwise IMA > will deny the operation if appraisal is in enforcing mode. With digest > lists it is possible to appraise files in the initial ram disk without > including extended attributes (the default policy excludes those files). There are a number of people interested in extending CPIO to support extended attributes, not just for IMA-appraisal. (Years ago I started but unfortunately haven't had time to finish it.) Isn't the right solution to add extended attribute support to CPIO? > The second reason is that appraisal has to be temporarily disabled > because the file containing digest list metadata is not signed. The same > happens when loading a public key (check ima_load_x509() in ima_init.c). In terms of the x509 certificate, in order to validate the file containing the x509 certificate, there needs to be a key on the IMA keyring. Since x509 certificates themselves are signed by a key on the builtin keyring, it is safe to load them on the IMA keyring without first validating the file signature. Once a public key is loaded on the IMA keyring, all other file signatures can be appraised. There's no need for treating the digest list file any differently than other files, as there is for the x509 certificate. Mimi
Re: [PATCH v2 06/15] ima: add parser of digest lists metadata
Quoting Mimi Zohar (zo...@linux.vnet.ibm.com): > On Mon, 2017-11-20 at 10:40 +0100, Roberto Sassu wrote: > > On 11/19/2017 12:23 AM, Mimi Zohar wrote: > > > Hi Serge, > > > > > > On Fri, 2017-11-17 at 22:20 -0600, Serge E. Hallyn wrote: > > >> On Tue, Nov 07, 2017 at 11:37:01AM +0100, Roberto Sassu wrote: > > >>> from a predefined position (/etc/ima/digest_lists/metadata), when rootfs > > >>> becomes available. Digest lists must be loaded before IMA appraisal is > > >>> in > > >>> enforcing mode. > > >> > > >> I'm sure there's a good reason for it, but this seems weird to me. > > >> Why read it from a file on disk instead of accepting it through say > > >> a securityfile write? > > > > There are two reasons. > > > > Digest lists must be loaded before any file is accessed, otherwise IMA > > will deny the operation if appraisal is in enforcing mode. With digest > > lists it is possible to appraise files in the initial ram disk without > > including extended attributes (the default policy excludes those files). > > There are a number of people interested in extending CPIO to support > extended attributes, not just for IMA-appraisal. (Years ago I started > but unfortunately haven't had time to finish it.) Isn't the right > solution to add extended attribute support to CPIO? (For the record) Yes, yes it is.