> I wondered if it were possible to do something like compute a checksum
> of images before running them and compare with a database of digitally
> signed checksums, or do the old VMS thing and assign images network
> privileges. I had thought to write a daemon that occasionally runs through
> /proc/*/exe and checks things.
>
> It occurs to me that the Java community has been through all this already,
> though I get the impression that signing of objects is pretty rare still,
> and the tools I had seen for signing Netscape applets were commercial.
>
>
> thoughts ?
> ideas ?
> "been there, done that" ?
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.
As long as the crackers have access to the open source of the
anti-cracking daemons and tools you are using to try to control them,
you are forever going to be trying to lock a door in a universe where
unscrupulous locksmiths always have access to the door. Not that there
isn't a benefit in adding another security layer for the crackers to
have to master -- it is at least another place for them to make mistakes
and perhaps ups the ante of difficulty so you only get nailed by the
better quality of cracker and not the riffraff off of the street, so to
speak, at least until the rootkit comes out that encapsulates all the
work done by the Ubercracker to get into systems thus protected.
Note that in endgame 2 (snoop and steal) or in endgame 3 (just steal all
the useful and possibly valuable software and data on your system) there
is more than just the macho incentive that drives the riffraff cracker.
The crackers derive real value worth money from their success, not just
bragging rights to their K001 friends. Somebody who expects to make
hundreds of thousands of dollars from their cracking activities is going
to take the time to carefully develop counter-countermeasures to any
countermeasure you dream up and actually publish. This situation is
bound to become more and more common. Want to increase the
profitability of your HMO? Find out how to steal hospital or employment
data on patients seeking insurance and deny coverage to the sick, lame
and lazy. Want to make money selling marketing lists? Set up traps
like those of the Russians that you describe. Want to succeed in
politics? Electro-Watergate is just around the corner, if any
presidential candidates have dirt recorded on them in any database in
the world, some dirtball will undoubtedly soon winkle it out -- and sell
it.
There are still some strategies that are reasonably likely to protect
hosts (mostly ones that involve really carefully monitoring one's
system, knowing what one is doing, not being careless, more than the use
of any specific tools). I'm certain that this subject gives nightmares
to e.g. red hat/rufus folks and to the debian package site folks. After
all, they could arguably be sued if somebody succeeded in trojaning say,
the master copy of the 6.1 distribution on the red hat ftp site and
somebody lost money as a consequence. Even without being sued, think of
how their corporate reputation would suffer ("Red Hat cannot even keep
their OWN website safe, how can they protect ours...").
The strategic defense that I think is "best" for midsize domains that
require a fair amount of "free access" (like a University) is to adopt
an "inside out firewall", or "ring of defences" with increasing layers
of security from the outside in rather than from the inside out. In this
strategy, each interior layer to safeguards the ones outside. For
example, you might have one (or more) "totally defended" box that can
only be accessed from the physical console kept in a locked room and
with an attached lineprinter that makes hardcopies of all the logs in
realtime so electronic deletion is literally impossible. This box might
offer >>only<< a (carefully sanitized and scrutinized and
buffer-overwrite-bug-free) syslogd as an incoming connection, for
example.. This box might protect a set of limited access servers that
are sufficiently complex that mere rootkits are unlikely to succeed by
logging >>all<< activity on those servers -- hopefully on a time/event
granularity that would permit any unauthorized intrusion to be detected
without exception and logged on the central host where the cracker
cannot possibly get at it.
Those servers might then serve (and protect) a collection of relatively
secure workstations with normal (but sensible and tcp-wrapped) port
offerings. With a clever enough arrangement of RO mounts of space from
the protected servers, you could at least arrange a system that would
have to have the kernel itself compromised in order to hide a cracker,
which would in turn require a reboot (red flag) and/or leave time for
the crack to be revealed in the logs. Around these there might be an
even lower security ring of insecure hosts (visiting laptops, insecure
OS architectures, and so forth) that are on the network but provide few
services and receive little trust.
Note that this is a sort of feudal arrangement, with the castle keep at
the center protecting the castle, the castle protecting the town, and
possible with the town protecting an even lower security ring of
peasants (e.g. WinXX stations, Macintoads). The systems administrator
is the feudal lord who sits in the keep and controls the castle while
jealously guarding their (IP) domain. Smarter than trying to build the
Great Wall of China or a Maginot Line (to cite two famous failures of
the firewall strategy:-) around the whole thing.
To keep this conversation relevant to a kernel list: Rather than trying
to provide the protection you suggest via a daemon, I'd suggest trying
to provide it with a kernel module. A daemon can be caught, controlled,
killed, replaced, its port saturated and blocked. A kernel module,
especially if it is written to be "insert only" and essentially crash a
system with lots of loud and dire warnings piped directly into a port on
a truly secure host if it were to be removed or reinserted or the system
was tampered with in certain key ways, might provide protection at a
level where crackers couldn't (easily, at least) defeat it with scripted
"smart" binaries in a compromised system. At the very least you could
WAY up the ante -- somebody would likely have to work directly with
/dev/kmem to rewrite part of a running kernel to defeat the protection.
If they're THAT good, what the hell, let them HAVE the bloody system.
They deserve it.
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/