> The way to fix these types of problems is to add some kind of digital
> signatures to modules and executables (and shared libs, loaders, etc,
> everything in the chain).
And what do you do, if the hacker replaces your kernel image with an
image:
- that treats his/her signed binaries automatically suid-root? *wonder*
- and stealths the reboot? (uptime, etc.)
There is no 100% bulletproof system, but a well administered system is
probably more secure than a system that is just installed, and afterwards
the ``admin'' has no time to take care of the system. If the system is
critical, than you need a good admin, probably a second logging host for
syslogd behind a 99.99% firewall (just let the syslog stuff in, nothing
else!), a pager for the admin, ...
>
> Even as root, if I don't have access to the signing program and signature
> information, and the object isn't signed by a recognized location (e.g.
> Debian or Redhat), it wouldn't allow root to do anything a normal user
> couldn't do - the euid would be permanently downgraded for unsigned
> executables. viri couldn't compromise executables. Hackers could replace
> some utilities with compromised versions, but the tracks would be more
> obvious since they would need to leave the signed versions around.
What about software that needs suid stuff, buit isn't included by Redhat?
Doesn't bite it. And if you require just a signature, then you have
the Active-X technology, where a nice analogy applies:
- As every citizen in this country (that europe here *grin*) is required
to carry a id at all times here, (that's more or less a kind ob physical
signature *grin*)
- one should leave ones home open. (The thief is required to carry a ID,
and if you want to be very secure, you can just install a logging lock
that opens for all IDs, hahaha)
> It would still require care since any system can be defeated, but making
> it more difficult could eliminate some attacks.
It wouldn't help it more, than nowadays a clean system gives you, as you
would still need a boot disc that contains a secure kernel, that hasn't
been tampered with.
> There are a few problems. DS requires crypto, and that can create export
> problems with the code. Crypto is big - the DS algorithm would eat
> another few hundred K out of the kernel.
It would give very little added security (you can do cryptographic
checksums nowadays offline too), and ``cost'' very much. (consider US
export regulation, kernel size, etc.)
Andreas