> 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.
Perhaps we're talking about different problems altogether.
A certification boot/rescue floppy is good, sure, for right when you
think you've just been cracked or perhaps to use on a very long rotation
basis, and I've used them for that purpose for years. It is useless in
even a modest size organization in any other context. Surely you don't
advocate using such a floppy every day on every machine in a large
organization, and even if you did this is far too large a time
granularity to do you any significant good.
My remarks and comments on trying to do the certification with a daemon
were addressed to the issue of trying to detect a crack in real time or
during a regular and routine fine-granularity scan, not long after the
fact or after a floppy-based reboot, and I even tried to make them
relevant to the kernel list (rather than yet another security rant) by
pointing out that -- as a kernel module rather than as a daemon -- the
idea had considerable merit.
> 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.
Hmmm, I wasn't aware that I was advocating security through obscurity
(and yes, I'm pretty familiar with the longstanding debate on open
source security and even agree with you in a lackadaisical sort of way).
Security by personal vigilance, yes, that I was advocating.
Well-defended servers I was also advocating, but that is hardly radical
-- most of the sysadmins I know in open environments like a University
embrace the "feudal castle" defense strategy in one form or another
simply because they cannot possibly exert enough control to totally
secure hundreds of workstations running three or four operating systems
being used by thousands of users (including many who login from remote
sites that may well have been cracked, providing instant access into the
best defended network in the universe). Keeping those basically
untrusted users (many of them are students, after all:-) OFF their
servers and logging all workstation activity immediately to secure
loghost servers at least requires crackers to crack the next (much
tougher) tier in their defenses to make really significant gains.
Again, to try to keep the discussion relevant to the proposed daemon, I
think that we'd agree that relying on a locally installed MD5 as a
cron-driven tool to detect cracks on a system is of far less value than
one might expect, and that the RO floppy, however valuable in its place,
isn't a scalable alternative. On systems with local disks, crackers
simply and routinely replace the MD5 and ps and ls and so forth binaries
you use to do most systems checks now (I know this for a fact as I was
cracked -- again -- embarrassingly recently). Crackers would simply
replace the "MD5 daemon" if one were developed along with the rest,
unless it were somehow set up so that shutting it down or replacing it
was itself a signal that the system was cracked. Note that I'm ASSUMING
that the MD5 source or MD5 daemon source is and properly should be open,
but their openness or closedness is irrelevant if they are destined to
be replaced instantly upon a successful crack.
Now:
a) I have yet to hear of a "publically scrutinized, easy to use and
unintrusive" open SECURITY system that a bad guy cannot take apart just
as carefully as it is originally put together and reassemble into a
functional simulacrum that allows them to exist within its aegis
unobserved. That doesn't mean that one cannot exist; just that I don't
think that one does now. rootkits are just one example of this process
in action, and fairly clumsy ones at that. More complex tools just make
crackers work harder (not a bad thing at all;-) but what is needed is a
primary security certification tool that absolutely cannot be subverted
without crashing the system.
b) You are obviously a fairly talented guy who knows a lot about
security. I (immodestly enough) know a bit too; at least I've been
doing systems work long enough to have learned a few things. However,
the world is full of total and complete systems neophytes who are now
installing and running linux. Some are running it on personal boxes.
Others are running whole networks (shudder). Most of these systems are
on the Internet and hence vulnerable to a wide range of attacks. Many
of the owners of these systems haven't the faintest clue that something
like a "security upgrade" exists and couldn't build a kernel if their
life depended on it -- until right after the first time that they are
cracked. There will >>always<< be a time-delay between the development
of "solutions" in the open source community and the distribution of
those solutions to the rest of the world, and crackers will >>always<<
exploit that interval. Perfect security is no more possible than a
world free from disease; the germs evolve faster than we do.
I was intrigued by the daemon suggestion because -- running as a kernel
module that cannot be tampered with without destroying the integrity of
the kernel itself (except perhaps by God's Own cracker, software being,
after all, software) -- it actually sounded like it MIGHT form the basis
for a scalable, open source solution to at least part of both a) and b).
Perhaps I'm wrong. But it seems like it would be possible to make a
kernel module non-removable and tamper proof (two key requirements).
The kernel doesn't need to go through a subvertable layer to use the
network. I suspect that a kernel+module could be designed that just
might be able to at least certify selected certification software as it
is loaded and run, and that might just be enough to make it MUCH harder
to crack and encapsulate.
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/