[lug] newbie question - rc.sysinit

[Chris Riddoch]

"D. Stimits" <stimits at idcomm.com> writes:

> Chris Riddoch wrote:
> > 
> > <snip>
> > 
> > Having followed this, and a couple other threads for a while, the idea
> > of having signatures on kernel modules sounds almost feasable, except
> > for a couple problems...
> > 
> > Someone with root access can look at any area of memory or the hard
> > drive.  The private key has to be kept somewhere... and the
> > passphrase, too, if you expect modules to be able to autoload without
> > the administrator sitting in front of the keyboard.
> 
> Part of this is the art of steganography...hiding data within data. A
> naive implementation might put the means to sign or verify signature in
> an easily altered location.


Right, right. But the problem is, you've got to have the code that
will perform the steganography somewhere in the kernel. That could be
analyzed to see what exactly the kernel does in order to get the
signature. 

> It should also be possible to force required memory locations to be
> read only, enforced by cpu hardware.

Well, my knowledge of hardware-supported limits on memory access is
limited to a class on assembly language and a couple weeks where we
discussed attributes on memory pages.  But the problem remains, if
root can make it read-only, root can also make it read-write.

> > Seems that the best way to really be secure about this would be to
> > build a kernel *without* module support.  Is anybody quite sure that
> > this would completely remove the ability to add modules?
> 
> You can, but some features are only available in modules.

Well, the more security you have, the more you encroach on usability.
The kind of security we're talking about here would rather severely
damage the sort of usability you'd expect on a desktop.

> Then you still have the problem of the kernel image itself being
> replaced, and re-running lilo.

True, there's more ways to do it.

> This is one place where bios virus options can be used
> to stop remote writes of boot sectors, but not of the image itself (it
> is possible to force a replacement kernel to be put at the original
> inode location, avoiding the problems of boot sector protection).

Hopefully your bios isn't stored in flash memory.  Otherwise someone
could change your bios to disable the virus protection, and probably
disable any password protection.  The bios is flashable, most of the
time.

> But a real win is not to cripple your machine, but to have it fully
> available while still being problematic for script kiddies to crack.

Well, I think there are a few options, depending on what level of
security you want.

1) Take firewalling, traffic analysis, security updates, and kernel
updates seriously.

2) All of #1, and do code reviews yourself.

3) Unplug yourself from the network.

If it were me, and I had the time, I'd do #2. As it is, I just do #1
and trust the Debian folk to do updates in a timely manner.

> There are not very many real experts that go around doing these things,
> often it is someone with little knowledge and a script, or just moderate
> knowledge capable of altering things on existing scripts. Once you use
> steganography, the attacker will be seriously challenged.

I don't think that's your silver bullet here.  There's only so much
you can do to hide it, because something executable has to be able to
get at it.  It has to get unraveled and unencrypted and extracted
*somehow*, after all, and the mechanism for doing so can be watched
while it's happening.

> > Even then, I suppose, the infinitely-capable adversary could
> > binary-patch the kernel's area of memory while it's running. Heh.

> Yup. You could take steps to avoid that vulnerability though. Hiding the
> data is one means, though there are others.

The best way to hide it would be to send a request to a machine whose
only purpose is to check if the kernel is allowed to load the
module. It could even *copy* the module to the other computer so it
could check the actual module, which would then send a message back
granting or denying the ability.  The whole exchange would have to be
done in some way to guarantee that each computer is, and is doing,
what it claims.

The basic rule is, you can't trust a computer if it's been rooted.

The other thing is, none of this is necessary for handling your
average script kiddie.  It's the determined person whose only target
is your computer that you need to be worried about.

--
Chris Riddoch         |  epistemological
socket at peakpeak.com   |  humility