Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote:
> 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.
You need to keep it somewhere if you ever want to build more modules
that that kernel will load. I don't know why I assumed it would be
stored in the kernel image.
>
> 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
>
Hmm, if you compiled on a separate machine, or kept the key on a
floppy, you could do make change the last step to "get all traces of
the key off the 'secure' machine".
> > 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.
Yes, that's what I was thinking too.
>
> > 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).
exactly. starting with the signing and IO protecting would be a very
good start.
As for secure block devs, you could have the kernel drop the ability
to write to certain partitions of certain disks, or something like
that. Blocking writes to mounted partitions wouldn't help for
partitions that can be unmounted and remounted easily. (writes to the
whole-drive block devices would have to go through the same checks, or
maybe even be blocked entirely if they fell within space allocated to
a partition.) If this got done, the signing idea would kick ass.
As it is, it's just pretty good...
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@llama.nslug. , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Reply to: