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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
