RE: F36 Change: DIGLIM (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux