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.
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.
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)?
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.
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.
This will make testing easier, and not preclude systems without an
initrd.
When a file is accessed, IMA calculates the file digest and queries
it with DIGLIM
All files? What does "accessed" mean exactly in this context?
When packages are installed or removed, the kernel hash table is
kept
synchronized with a new rpm plugin.
Does this mean that old hashes are removed from the kernel after a
package has been upgraded?
Are there any race conditions: e.g. when a new version of a package is
installed, at what point in time are the new hashes uploaded? Something
may be executed concurrently with the package upgrade, which would mean
that the new hashes would need to be uploaded before any files land on
disk.
And vice versa, if a file is opened, and later executed with fexecve(2),
and concurrently the package is upgraded between those two steps,
will the execution fail?
Zbyszek