Message-ID: <d6590f96cfbd4411a0ae6e8589216fe1@huawei.com>
Date:   Thu, 5 Aug 2021 17:04:46 +0000
From:   Roberto Sassu <roberto.sassu@...wei.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "mchehab+huawei@...nel.org" <mchehab+huawei@...nel.org>
CC:     "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Eric Snowberg <eric.snowberg@...cle.com>
Subject: RE: [RFC][PATCH v2 06/12] diglim: Interfaces - digest_list_add,
 digest_list_del

> From: Mimi Zohar [mailto:zohar@...ux.ibm.com]
> Sent: Thursday, August 5, 2021 5:38 PM
> [Cc'ing Eric Snowberg]
> 
> Hi Roberto,
> 
> On Mon, 2021-08-02 at 16:54 +0000, Roberto Sassu wrote:
> 
> > > > Properly identifying (all) user space parser(s) would be critical.  It
> > > > would be simpler and  safer to require the converted data be signed.
> >
> > When a process directly uploads a buffer to the kernel, the actions are
> > added to a digest list depending on the result of ima_measure_critical_data()
> > and from the actions attached to the process credentials and set by the
> > new LSM.
> >
> > If a process fails the identification, the actions in the process credentials
> > remain zero and the digest lists the process uploads will be ignored by IMA.
> >
> > The actions in the process credentials are set with the actions performed
> > on the executable by IMA, only if the digest of the executable is found in
> > a digest list and the digest list type is COMPACT_PARSER. The parser is
> > statically linked.
> >
> > The digest list for the parser can be generated at the end of the
> > building process and signed similarly to kernel modules (for SUSE,
> > with pesign-obs-integration). This is the only exception to handle,
> > other packages are not affected.
> 
> Ok, so to boot strap the set of permitted digest list parsers, the
> digest list signature is an appended signature, generated by the build
> process.  The key needed for verifying the signature would already be
> loaded on the builtin keyring.

Hi Mimi

yes. RPM headers will have an appended signature too, so that
appraisal will work.

> > After the parser has been identified, each file operation is monitored.
> 
> Does the new LSM need to monitor all file opens?

I would say yes. In the threat model, root is untrusted and
can potentially interfere with the conversion of the original
digest lists. Other than monitoring file operations, I'm also
denying ptraces on the parser. Hopefully this would be
sufficient, but any suggestion is more than welcome.

The good thing is that the policy of the new LSM is applied
to the processes that are successfully identified as parser.
Other processes are mostly unaffected.

The only limitation the new LSM would introduce is that
the files being used by the parser are write-locked until
the parser releases them (if files are already opened for
writing by other processes, the LSM would mark the parser
as untrusted and will not apply any IMA actions to the digest
lists the parser uploads).

It is probably a good idea to send the patch, after I finish
testing it. I will send also another patch for loading digest
lists during kernel initialization (with the two new patches
the non-IMA part would be complete).

> > The LSM has to explicitly perform a second open to ensure that
> > the file is measured/appraised before the integrity_iint_cache structure
> > is retrieved (because IMA is called after all LSMs).
> >
> > If an action is missing from the integrity_iint_cache structure, it
> > will be cleared by the LSM in the actions attached to the process
> > credentials, and will not be added to the digest list being uploaded.
> >
> > > I agree, it would be much easier. However, it would require changes
> > > to the building infrastructure of Linux distribution vendors, which
> > > might limit the applicability of DIGLIM.
> > >
> 
> I understand, but instead of the distros signing the compact digest
> lists, with Eric's  "Enroll kernel keys thru MOK" patch set, the
> customer/end user could have more control over which file digests are
> permitted on a per system basis.

Yes, generating custom digest lists is supported and needed if
users want to run their own applications, when appraisal is
enforced. But I like the idea that, if users simply want to just run
anything the distribution provides, they have everything they
need. Theoretically, users will be able to run appraisal in enforcing
mode at the first boot after installation.

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli

> > > With the user space parser taking care of the conversion, distributions
> > > can do appraisal of executables and shared libraries with an update of:
> > > - the kernel: to add DIGLIM
> > > - dracut: to add required digest lists in the initial ram disk
> > > - rpm (plugin): to extract the RPM header and its signature and write
> > >   them to a file that is uploaded to the kernel by the user space parser
> > >
> > > I'm planning to append the signature at the end of the RPM header
> > > (and use appraise_type=modsig) to avoid the dependency on the
> > > 'initramfs: add support for xattrs in the initial ram disk' patch set
> > > (which I might try to resume in the future).
> 
> Based on your explanation above, I surmised as much.
> 
> thanks,
> 
> Mimi

Powered by blists - more mailing lists