Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL

[Vivek Goyal]

On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote:
> Quoting Vivek Goyal (vgoyal@xxxxxxxxxx):
> ...
> > Giving CAP_MODIFY_KERNEL to processess upon signature verification
> > will simplify things a bit.
> > 
> > Only thing is that signature verification alone is not sufficient. We
> > also need to make sure after signature verification executable can
> > not be modified in memory in any way. So that means atleast couple of
> > things.
> 
> Also what about context?  If I construct a mounts namespace a certain
> way, can I trick this executable into loading an old singed bzImage that
> I had laying around?

We were thinking that /sbin/kexec will need to verify bzImage signature
before loading it. 

Key for verification is in kernel so idea was to take kernel's help
in verifying signature.

Not sure how exactly the interface should look like. 

- I was thinking may be process can mmap() the bzImage with MAP_LOCKED.
  We can create additional flag say MAP_VERIFY_SIG_POST, which tries
  to verify signature/integrity of mapped region of file after mapping and
  locking pages and mmap() fails if signature verification fails.

There have been suggestions about creating new system call altogether.

> 
> ISTM the only sane thing to do, if you're going down this road,
> is to have CAP_MODIFIY_KERNEL pulled from bounding set for everyone
> except a getty started by init on ttyS0.  Then log in on serial
> to update.  Or run a damon with CAP_MODIFIY_KERNEL which listens
> to a init_net_ns netlink socket for very basic instructions, like
> "find and install latest signed bzImage in /boot".  Then you can
> at least trust that /boot for that daemon is not faked.

daemon does not have the key and can't verify signature of signed
bzImage. Even if it had the key, it can't trust the crypto code for
signature verification as none of that is signed.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/