linux-kernel - Re: [RFC][PATCH v2 06/12] diglim: Interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e886224b50195a2c1324c91b39514395e9780b06.camel@linux.ibm.com>
Date:   Thu, 05 Aug 2021 11:38:08 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Roberto Sassu <roberto.sassu@...wei.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

[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.

> 
> After the parser has been identified, each file operation is monitored.

Does the new LSM need to monitor all file opens?

> 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.

> > 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