Messages in this thread | | | Date | Wed, 15 Oct 1997 22:46:47 +0000 (GMT) | From | Andreas Kostyrka <> | Subject | Re: [linux-security] Malicious Linux modules (fwd) |
| |
On Wed, 15 Oct 1997 nospam-seesignature@ceddec.com wrote:
> 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
| |