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

[Andy Lutomirski <luto@amacapital.net>]

[-- Attachment #1: Type: text/plain, Size: 5008 bytes --]

On Aug 1, 2016 4:30 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
>
> On Mon, Aug 01, 2016 at 04:13:50PM -0700, Andy Lutomirski wrote:
> > On Aug 1, 2016 4:04 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
> > >
> > > 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@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.
> > >
> >
> > I'm not sure I understand what you mean.  What table would we look the
hash
> > up in?  What are we finding in that table?
>
> From the other subthread:
>
> > Then, to verify a signature, the kernel hashes the blob, generates its
> > own linux_blob_signed_data, memcmps it to the one that Kyle signed
> > (and rejects if they differ *at all*), and then verifies the
> > signature.  (Do not try to be clever and parse the supplied
> > linux_blob_signed_data -- there is a long and storied history of
> > equivalent ideas being implemented incorrectly, and I can dig out
> > literature references if you really want.  Just generate your own and
> > memcmp it, which leaves no room for ambiguity.)
> >
>
> So, I'm suggesting that when "the kernel hashes the blob", it use that
> hash to locate *which* "Kyle-signed" linux_blob_signed_data it needs to
> compare against.  That's all, just removing the filename from the
> equation. :-)

So Kyle would generate a list of signatures indexed by the blob's hash
instead of generating things like "iwlwifi-whatever.ucode.sig"?  Seems
okay.  It'll keep the existing hooks working, I think.  Of course, we still
need to check the "iwlwifi-whatever.ucode" bit to confirm that it matches
Kyle's signed data.

[-- Attachment #2: Type: text/html, Size: 6850 bytes --]