Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Mo, 2016-08-01 at 10:59 -0700, Andy Lutomirski wrote:

> Mimi, I'm curious: I don't fully understand what is covered by IMA
> policy.  How does the IMA kernel_read_file stuff deal with symlinks?
> For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
> /home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I symlink
> /lib/firmware/iwlwifi-8265-21.ucode to /home/badguy/something_else?
> Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?  The
> interesting case is where the "badguy" user is duly authorized to
> write to /home/badguy and holds whatever keys may be needed.

Lets step back a second.  In order for a key to be added to the IMA
keyring, the key must be signed by a key on the builtin keyring.  The
key on the builtin keyring can be compiled into the kernel image or
added post build using Mehmet Kayaalp's patches.

True, any key on the IMA keyring could be used to verify file signatures
(in IMA terminology appraise the file's integrity).  The enumeration is
a first step to making sure that only properly signed code is read by
the kernel.  The next step requires finer grain key management.  In
general, pathname based policies are not a good idea.  Whatever method
is defined, it should not be limited to just firmware or files read by
the kernel, but to all files.

Mimi