On Thu, 13 Jan 2005 02:05:55 GMT, ilovebread@go4.it said:
I have put up a little challenge for anyone to play with.
The challenge is to modify 3 specific files on the system.
I am granting full root access to everyone.
I presume you're familiar with Bruce Schneier's explanation of why
challenges like these rarely do anything to inspire confidence in your
system. If you're not, go read 'Secrets and Lies'. If you haven't
read that already, you're probably not qualified to design trusted systems.
Now, if you were to *explain* how your trusted system worked, and why
it should prevent the challenge, we *might* start thinking about taking
the challenge seriously. Wander over to the SELinux site, and look at
the amount of analysis work they've done. Creating a trusted system with
a useful amount of functionality is *hard*, and you've not shown us any
reason to think that your system is worth testing.
So what happens? The people who could mount a credible test probably
don't try it, because they can tell from what they've seen so far that
the scheme is probably flawed (I can't remember an open challenge that
*wasn't* flawed). So the only people who bother trying are script kiddies
and the like - giving you a false sense of confidence in its security.
And more snake oil gets sold.
If you want commentary from seriously clued people, try the following:
1) Explain in 3-4 paragraphs what your approach was to making a trusted
Linux system. Include enough information to prove that you've bothered
doing the research to find previous attempts, and why you didn't follow
their approaches (successful or not). Why is (or isn't) Bastille interesting,
for example? What issues do LIDS, GRSecurity, and SELinux have? Why
are you doing things similarly to them, or differently?
2) List the 4 or 5 most obvious classes of attack against your system, and
explain what you've done to *ensure* they won't work. This (a) keeps us from
wasting our time trying things that won't work, and (b) shows that you've
thought things through at least somewhat. What does your system do to
protect against a coding error in a set-UID program? What does it do to protect
against an exploitable kernel bug? What do you do about things like
resource starvation attacks? How do you prevent an 'insmod' of malicious
(or just buggy and exploitable) kernel modules?
And I assure you that *my* checklist of "things it has to do right before
we even *think* of calling it trusted" is *much* shorter than, say,
Steve Bellovin or Matt Blaze's (and again, if you don't understand this
comment, you probably should stay away from trusted system design till
you *do*..)
pgpKJBaxoip6b.pgp
Description: PGP signature
