[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A question about Knark and modules



On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote:
> I like the package signing idea.  That would be cool.  That way, you
> could still load and unload modules.  I like being able to do that.
> One obvious problem with the scheme is that an attacker could
> potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and
> sign their own module.  This can be overcome if we give up the ability

how?  the kernel does not need the private key to verify the
signature.  

replacing the kernel image and rebooting would be another way to get
around this. as would injecting code into /dev/mem.  

> to compile more modules for that kernel after we finish compiling it:
>  - Generate a key pair during kernel compilation (RSA would be a good
>      alg. for this).
>  - Sign the modules with one half of the key pair.
>  - store the other half of the key pair in the kernel image.
>  - _delete_ all traces of the key used to sign the modules.

yup

>  All that's needed to make this workable is to find a way to provide
> access to IO/device memory space for X11 without allowing read/write
> access to kernel memory.  This can't really be all that hard.  I think
> the kernel can tell when the memory address written to or mapped in
> /dev/mem is part of kernel memory by checking where the kernel is in
> memory.  A very restrictive raw mem device that only allowed processes
> to map PCI memory space, or maybe just PCI memory space that PCI
> devices reported in their configuration info, would do the job for
> X11.  (BTW, AGP acts like another PCI bus).  Limiting things to only
> PCI-reported memory spaces would stop access from user space to ISA
> memory, but who would want to do that anyway...

this would be a good idea anyway, it might reduce the possiblity of X
killing the entire box whenever it hiccups and scribbles random
memory.  

>  I like this idea.  It would kick ass, so we should do it.

you would need to fix filesystem immutability and block device access
as well.   currently lcap CAP_LINUX_IMMUTABLE is useless since there
is no way to deny root the ability to write directly to /dev/hda* and
remove the immutable bits (ive written a script to remove chattr +i
and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set,
no reboot required). 

otherwise the attacker can just replace your kernel image and reboot
(which is of course fairly noticable). 

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgpKvSLRyC5KS.pgp
Description: PGP signature


Reply to: