[...]
> The problem is that >>any<< daemon, running basically outside of the
> kernel as an ordinary task, just continues a vicious cycle of:
>
> a: (bad guys) develop clever(er) exploit
> (good guys) develop clever(er) counterexploit
> goto a:
>
> How do you protect against corruption/replacement of the daemon software
> that checks the images? Quid custode custodes? Right now, "rootkit"
> packages come with pre-scripted cracking tools that, when they succeed,
> encapsulate the cracker invisibly, blinding the tools required to "see"
> them. This just adds another tool or layer of tools they have to
> replace. After all, how are you to know if the daemon you started is
> truly the daemon that is currently running if the cracker controls the
> daemon, ps, ls, and all that? They'll all lie to you, just like they do
> now for many rootkits.
Then you need a way to certify what is on your system, probably off-line: A
rescue-diskette style freestanding system that keeps the tools to check the
files on the system, and perhaps also a database of cryptographic hashes
for key system pieces.
The ideas you seem to advocate are called "security through obscurity" in
crypto circles, where they have been thoroughly discredited. What is needed
is publically scrutinized, easy to use and unintrusive systems that rely on
secure mechanisms (i.e., crypto keys, secure hashes) to verify integrity.
If the source is open, everybody will look it over, and flaws will be found
and fixed quickly. If the source is closed, flaws will be discovered a bit
slower by the wrong people, and never fixed.
Packages today are distributed with MD5 hashes, and signed with PGP/GPG, so
it is _very_ hard to troyan a package and getting away with it for any
amount of time.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/