[vox-tech] Linux file/module security proposal.

[Bill Broadley]

Wes Hardaker wrote:
>>>>>> On Wed, 20 Aug 2008 22:29:57 -0700, Bill Broadley <bill at cse.ucdavis.edu> said:
> 
> BB> So would you use such a mirror to protect against trojan binaries
> BB> and kernel modules?  Why?  Why not?  Can you think of a better
> BB> approach?
> 
> Well, it all comes down to how much of the system the hacker owns.  If
> he has root on your machine he's likely inserted a kernel module to hide
> things or change things 

Right, but if the kernel only accepts signed binaries then he can't.

> (many of them actually still report proper
> md5sums for a hacked binary because they've hacked the kernel to be
> different for reading vs executing something).

Very true, but the attack by insmod won't work if the kernel only accepts
signed modules.

> So online scanning is
> actually not necessarily effective (and taking a machine down on a
> regular basis to boot off a trusted medium to do scanning is obviously
> not ideal, especially for servers).

Right.

> You have to trust someone to get your software from.

Sort of, in the typical environment you have to trust the person who signed 
the packages (redhat or ubuntu), but not the mirror... at least not much.  You 
do have to verify that the key that signed the packages is the key you expect 
from the package signer.

> It may be that you
> can set up a building repository as you've described, but as you say you
> have to trust it (more than you trust the original site). 

Exactly, so would it be worth it to prevent a hacker with root access from 
tweaking your kernel with a kernel module or running trojan binaries to steal 
keystrokes, passwords, and the like.

> Unless it's
> more secure than the original distribution site it doesn't help you.

I think it definitely would be, it's not magic of course, it would be an 
improvement that would move the weak link to other areas, additional things 
would be necessary to significantly harden a system, like:
* protect /dev/mem and /dev/kmem to avoid writing a new key
* protect digsig module from being unloaded
* configure BIOS to only boot from a bootloader on RO media to avoid
   tweaking grub to run a new kernel and/or initrd
* public key should be only able to be loaded once, and loaded early, i.e.
   from the initrd on the RO media.

> Plus as you rebuild a ton of packages, what's to say that the sources
> you're pulling from don't have trojans in it? 

Well, I'd get them from official mirrors and check that the signature matches
the key that I'd get out of band, i.e. http://redhat.com/cert-key or whatever 
it is.

> Rebuilding the package
> doesn't help if it's coming from the same sources.

Agreed, if the package is hacked by redhat it's still hacked.  This is just a 
mechanism to prevent any non-official binary, library, or kernel module from
running, so the typically hacker that buffer overflows and transfers a new
ssh, sshd, df, ps, and friends finds they don't run.  When they try to
insmod hide_me.ko that also fails.

> Finally, if they have root on your local machine, there is nothing
> preventing them from installing bogus GPG keys or worse binaries that
> report they've checked the signature but actually don't. 

Granted, it's a piece.  But kernel/binary signing can help maintain the high 
ground.  You can keep the kernel from being compromised so it won't lie to 
you, same with glibc, and of course tripwire.  Not that all the pieces I 
discuss are perfect, but they have the right idea.  There do seem to be fixes 
for all the attacks I know of, this isn't just obfuscation.

 > The
> cryptographic checks *only* work if your machine hasn't been broken into
> in the first place.  Afterward, it's far too late.

Agreed.  But I believe this approach could dramatically raise the bar to a 
successful hack and provide a fair bit of protection even in the case where a 
hacker gets root.  While a hacker still could cause many problems with root 
even without hacking the kernel or binaries, but it would be much easier
to contain and recover from if you know you can trust your kernel and binaries.

Hopefully that all makes sense.  Some of the pieces I was proposing is bsign 
for signing elf binaries (and turning off a.out and others in the kernel). 
Then using digsig as the kernel module to prevent unsigned binaries from 
running.  Redhat has a kernel patch that's been in use for years on fedora and 
centos that's mostly used as a support tool.  I.e. support folks can tell if 
you are running non-official modules from the flags in /proc/modules as well 
as some of the syntax in oops messages.

So my proposal is more of a, would you use it and do you think it's worth 
heading off in this direction?  It seems to work quite well for maintaining 
the integrity of various embedded systems.  I think that nature of opensource 
and the ability to run a local mirror would make it rather easy to get ahead 
of the curve.  From what I can tell this is where things are going, and redhat 
is already there with the kernel modules (if you use the right boot flags).