> 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.)
lilo or loadlin can also be set to check for digital signatures. No sig,
no load. Also, it would be difficult to replace the kernel image if it is
kept on a different (inaccessible) disk/partition/etc. or write protected
floppy, or CD-ROM. Further, the kernel would have to be built to include
the proper hardware (and fiddling with the modversions to scramble or
secure-hash the checksums could make this quite difficult).
> 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, ...
Agreed.
> > 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*)
Instead of making up myths, you might ask how I would implement it.
I was thinking of a "bless" program that would create and attach the
digital signature. You would have your own key management, so you could
resign everything yourself and delete redhat, etc. from your keyring
(haven't you ever used PGP?). One mode could be to simply resign
everything with a distributor signature to your signature. For a locally
compiled suid program, you simply have to add a "bless <progname>" and
supply the passphrase when asked.
Active X uses digital signatures for wide area authentication, so I can go
to strange sites and know who to sue if the app kills my hard drive. That
is different than having local or vendor signatures only and controllilng
them yourself.
Redhat already signs the packages themselves using PGP.
> - 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)
I am not saying that digital signatures were any panacea or were
substitutes for other security measures. They would simply prevent any
suid or non-suid programs from running with root privileges, so simply
compiling a program or downloading a new binary would not be able to
compromise a system (and would be detected - knowing a system has been
compromised is also important).
> > 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.
e.g. leave a write protected floppy with the kernel image. The interlock
is hardware.
> > 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.)
It would give a large amount of added security (other things would need
tightening) with a large cost. Digital signatures are not *merely*
cryptographic checksums (I assume you mean things like MD5 and SHA by the
term).
The security gained would be preventing someone with root privileges from
installing compromised objects or executables - much as they cannot easily
determine the root password - they can change it, or compromise the entire
passwording system, but cannot determine the original root password.
--- reply to tzeruch - at - ceddec - dot - com ---