> From: Lennart Poettering [mailto:mzerqung@xxxxxxxxxxx] > Sent: Monday, January 3, 2022 1:33 PM > On Do, 30.12.21 13:04, Fedora Development ML (devel@xxxxxxxxxxxxxxxxxxxxxxx) > wrote: > > > > From: Zbigniew Jędrzejewski-Szmek [mailto:zbyszek@xxxxxxxxx] > > > 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. > > Wouldn't it make more sense to push the digest lists into the kernel > by simpler means, before any userspace runs? e.g. just pick it up from > some fixed path in the file system, directly from the kernel, like the > firmware is picked up, or the ACPI DSDT tables are picked up. That way > you can just compile the digest lists trivially into a cpio you pass as extra > initrd to the kernel, and things will just work without "uploading", > without happing any intermediary userspace process around that needs > to run to upload anything... They'd be available from the first moment > on, from kernel code, without any userspace interfering. Definitely yes. It partially works that way: there is a loader in the kernel, called when rootfs becomes available, which get a fixed path from the kernel configuration and loads any digest list that is in the directory. That would work if all digest lists are supported by the kernel. The first version worked that way, I developed a simple parser of RPM headers, so that the kernel could process then without having an additional user space process. Much better in term of protection: no interference with other user space processes that should be handled with an ad-hoc LSM, no time to measure time to use race condition. However, it was pointed out by Matthew Garrett that this approach is not scalable. Whenever a new digest list format is introduced, a new parser should be added to the kernel, with the risks associated. Before proposing this fine-tuned protection you saw in the last iteration of the patches, we considered to generate a digest list in the native format for each package we build (currently openEuler works that way), and to inject it in the package (without changing existing spec files). That approach worked at the cost of modifying the rpm source code to pass the list of files being built and their digest to an external digest list generator, which returned the digest list. The RPM header was then modified to include the generated digest list. That removed the need for an additional user space parser, as everything could be handled by the kernel, but the complexity of the solution and the fact that it requires a mass rebuild suggested that we should abandon this approach in favor of more complexity at digest list loading time. I kept the current proposal simple for easier understanding, but a possible application of this user space loading could be that digest lists could be used for metadata protection too (including the SELinux labels). EVM would query digest lists in the same way IMA does (there is still the problem of unpredictable UIDs/GIDs that need to be solved). The role of the user space parser would be to calculate metadata digests (by querying libselinux, which would read file contexts), and to upload them to the kernel. > Static linking is a mess. User-mode helper is an atrocity: no new > kernel callouts should be introduced these days, that bypass userspace > service management, that are not properly sorted into a cgroup and so > on. It all sounds to me as if this *really* isn't thought to the end, > and should not be adopted this way... Dynamic linking would be possible, but I'm not sure it would be easier. Now, although this is a system-wide change, I consider this approach self-contained: everything is needed to bootstrap DIGLIM is contained in the kernel-tools-diglim package. With dynamic linking, you also have to take care of all shared libraries. Since the parser is not yet functional (the kernel is in enforcing mode), you need to generate a digest list in the native format (in the spec file) for every shared library you want to load. I liked the fact that, once you have the modified kernel with the appropriate GPG keys, and kernel-tools-diglim, you are able to run IMA appraisal without additional effort for its management. Regarding how the user space parser is executed, I would consider alternative proposals. Maybe running the parser as the init process and switching to systemd after the digest lists are loaded? Thanks Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua _______________________________________________ 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
