On Thu, Dec 30, 2021 at 01:04:29PM +0000, Roberto Sassu via devel wrote: > > From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl] > > Sent: Thursday, December 30, 2021 1:02 PM > > The gist of the proposal is described thus: > > > The new feature behaves as follows. A modified kernel with the DIGLIM > > > patches will expose to user space an interface to add/remove file > > > digests from the kernel hash table. A user space parser, executed by > > > the kernel during early boot, parses RPM headers found in /etc/diglim > > > in the initial ram disk (included with a custom dracut script) and > > > uploads them to the kernel. When a file is accessed, IMA calculates > > > the file digest and queries it with DIGLIM. If the digest is found, > > > measurement is skipped and appraisal is successful. If the digest is > > > not found, a measurement of the file is performed and appraisal fails. > > > When packages are installed or removed, the kernel hash table is kept > > > synchronized with a new rpm plugin. > > > > This description is … short. > > I saw you asked more questions below. I will answer there. > > > > A user space parser, executed by the kernel during early boot > > > > Is it really executed by the kernel? This description makes it sound > > like a special old-hotplug-helper-style program that is spawned directly > > by the kernel. > > Yes, it must be executed before init, otherwise the kernel > would refuse to execute it. And probably, it must be executed > earlier than now, as I'm seeing that the kmod binary is being > executed (with the same mechanism, user-mode helper) before > the digest lists are uploaded to the kernel.
Normally ima policy would be loaded by systemd if /etc/ima/ima-policy is found… How does the loading of the digests relate to the loading of the ima policy? > The reason for the kernel denying any operation enforced > by the IMA policy would be that there are no file signatures > for appraisal. The digests loaded by the helper are used > instead. For the same reason, the digest of the helper itself > must be in the native format understood by the kernel > (the process of generation and signing is done in kernel.spec), > and the kernel must scan /etc/diglim to load the native > digest list before the helper is executed. > > > > parses RPM headers found in /etc/diglim in the initial ram disk > > > > In general we try not to stuff more things in /etc, especially when > > there is no reason to. Why doesn't the helper just read files from > > /var/lib/rpm (or whatever %_dbpath du jour)? > > The RPM DB cannot be loaded as it is. The kernel accepts a > file format similar to kernel modules, with appended signatures > (I added support for PGP appended signatures in IMA). Each RPM > header, together with its signature, must be written individually > in a file. > > Also files in other formats can be added to the same directory > (for example the user-generated digest lists). > > If there is a better place than /etc, it would be fine for me to > move the directory to a new location. Normally such files would go somewhere in /usr. In this case it makes sense put them next to the rpmdb files. If users are allowed to add more files, then those files provided by the admin should be in /etc. > > This opens a bigger design question: the implementation seems to be > > closely tied to a very specific boot sequence implementation: > > grub2 + dracut. Unfortunately this is made even more opaque by the > > text description which uses generic terms like "boot loader configuration" > > when talking about a script which is intimately tied to some obsolete > > imperative grub2 installation mechanism. > > Ok, sorry for the confusion. We just need to add few parameters > to the kernel command line, and include the digest lists in the > initial ram disk. For now, I'm excluding the implementation of a > custom script to select only the digest lists required for accessing > files in the initial ram disk. Hmm, so how does this work wrt. to transition to the host system? The system has many more files from more packages, and those packages are in different versions. > > It would be much better if instead the helper to upload the hashes > > to the kernel would be a generic tool that can be called whenever and > > from whatever environment. _Then_ you can add a dracut module to call > > it in the initrd, but that part should be a trivial wrapper, with all > > the "business logic" contained in the generic helper. > > Too late. > > Also it cannot be a generic tool. First it is statically linked, to > avoid depending on shared libraries for which a native digest > list must be generated. At least with a static binary, only one > file should be considered. > > Second, I had to develop an ad-hoc LSM to protect the helper > against the other root processes. The problem is that an attacker > might be able to tamper with the memory of the helper containing > the digests extracted from RPMs, before the digests are uploaded > to the kernel. Anything that the helper accesses must be inspected > by IMA to provide the guarantee that the helper was not tampered. OK, it sounds like I should read the patches now. Thank you for all the answers. I'll be back with more questions ;) Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
