> From: Mimi Zohar [mailto:zohar@xxxxxxxxxxxxx] > 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
