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

[Andy Lutomirski <luto@amacapital.net>]

On Mon, Aug 1, 2016 at 3:21 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 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.
>

Unless I'm mistaken (which is quite possible), IMA is primarily
intended to appraise the content of POSIX filesystems.  So, if IMA is
in use, then doing:

$ cat /foo/bar

should only succeed if /foo/bar is signed according to loaded policy.
It's the system administrator's decision what filesystem is actually
mounted at /foo, and root can presumably mess around with application
expectations by, say, bind-mounting something over /foo.

Modules and firmware are special: even root should not be able to
avoid the full signature policy.  This means that, for example:

# mount --bind /evil /lib/firmware

should not result in violating policy.  So the pathname should not be
used as such.  However, firmware is a bit special in that the driver
chooses the pathname to request, and it really does uniquely identify
the intended firmware.  So, when a driver asks for:

"iwlwifi-whatever.ucode"

and the driver core tries to read "/lib/firmware/iwlwifi-whatever.ucode"

it's entirely possible that we'll follow a symlink and end up
elsewhere (Fedora, for example, does exactly this), but the file
that's loaded should be appraised (or verified using a non-IMA means,
etc.) to verify that whatever blob gets found is actually signed by
the holder of an authorized key for the purpose of being used as
"iwlwifi-whatever.ucode".

The current API can't do this cleanly no matter how IMA implements the LSM hook.

--Andy