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

[Jason Cooper]

On Mon, Aug 01, 2016 at 03:36:51PM -0700, Andy Lutomirski wrote:
> On Mon, Aug 1, 2016 at 3:21 PM, Mimi Zohar <zohar at 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".

Assuming Andy's lightweight signature scheme, it would probably be best
to do a lookup based on the sha256 hash of the file.  Then pathnames
don't matter, and bad files don't even get to the signature checking
code.

thx,

Jason.