> > On Fri, 3 Dec 1999, Jeffrey B. Siegal wrote:
> >
> > > > How do you protect against corruption/replacement of the daemon software
> > > > that checks the images?
> > >
> > > Keep it in physically unwritable media, like a CD-R in a CD-ROM drive.
> >
> > How will it help if trojan already modified the kernel image?
>
> Or if the compiler you used was unsafe, or the compiler that built that
> compiler or..
>
> Mr Turning says "you lose" 8)
>
> More seriously I know of at least one bunch of people who not
> only audited Linux by hand, and each app they wanted but also audited gcc,
> and binutils built their trusted gcc with their own in house cc/libs and built
> everything with their trusted compiler set.
Which is the sort of thing you MUST do if you're writing for the NSA or
some other extremely fault/crack intolerant organization (like a major
bank). And even then it's hard to be "certain" that you're safe.
I don't think people commonly realize just how good the best crackers
are. Some of them are easily as good as a lot of the people who work on
the kernel, and work just as long and hard at what they do. They take
pride in their work and build toolsets that go far beyond the rootkits
that bounce around the net.
It really is a genetic/evolutionary sort of thing, with the crackers the
rapidly evolving bacteria looking for the weak points in a host's
defenses (and exchanging "genes" containing partial solutions they have
encountered so far) and the host lumbering along, always behind, engaged
in their own exchange of defensive genes to try to plug one hole after
another while new holes are constantly being introduced by the changing
nature of the universe and the exchange process itself.
There is little (I really mean "no") possibility of creating a
system/world safe from crackers, and there is a highly nonlinear
ascending cost/benefit relation that one must balance against your means
and needs. Think of the cost of daily reboots, cdrom drives or floppies
locked and loaded with hard media, certifying a system from the compiler
source on up, fascist management practices like prohibiting logins from
outside the organization altogether -- few individuals or organizations
have the means or need to go that far as it would cost far more in
productivity than the occasional crack costs to detect and repair. Most
professional sysadmins in a medium-to-low security environment get by
just fine with vigilance, a reasonable effort to close well known holes
as they are revealed (to keep the riffraff out:-) and of course GOOD
BACKUPS and just do a clean reinstall from secure media and redouble
vigilance if/when they are cracked.
I still do think that it would be just groovy if somebody were to work
out some way of elevating cracking encapsulation to the level of kernel
hacking -- having the kernel itself do something like a journalling
validation at startup and shutdown on a selected set of "frozen"
binaries and system config files in such a way that a cracker could only
mess with it with a VERY sophisticated toolset might raise the bar too
high for at least ordinary rootkits to work anymore. This would be a
blessing.
Once upon a time, if you were cracked and the cracker encapsulated you
at least knew that you'd been hit by a "pro". (There was one individual
who cracked Duke's CS department a decade or so ago who was so good that
the only way they could tell the person was "there" at all was with a
passive host monitoring the IP traffic. Not a needle, not a binary,
gave any hint that the person was connected and working on the system
when the person was connected and working on the system -- but that's
another story.)
Now any high school dweeb can find a site with a toolset all built and
scripted out for them that they can use to crack and encapsulate without
having any clue as to what they are doing and it's just a matter of luck
as to whether or not their toolset is good enough or designed properly
to work on your installation. A toolset that could do that while
operating on the memory image of a running kernel would have to be
awesome indeed and might actually take a year or so for high end
crackers to get running. It also would likely fail for each new
revision of the kernel and might even fail for different modular
configurations of the kernel. This might just allow the good guys to
stay ahead for a while.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu
-
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/