[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-security] Re: RedHat 5.X Security Book

On Fri, Jul 10, 1998 at 07:38:43AM -0300, Grant Taylor wrote:
[regarding <seifried seifried org>'s book]

> And note that while I don't think that your book will actually
> result in fully secure Linux systems run by neophytes, I do think
> it's a net improvement in the state of the world.  The more
> material out there for people to learn from, the better...

It therefore appears that everyone agrees that a Linux-specific
security book would be a Good Thing -- the disagreement, then,
appears to be about _why_ this would be so.

>>>>> <seifried seifried org> writes:                                
> > Theory is great but most people do not have the time, or technical
> > background to read PUIS. To draw an analogy:
> >
> [ vehicle maintenance analogy ]

> Absolutely.  But network security is more complex than car
> maintenance.  It also differs in that "99% secure" isn't significantly
> better than "40% secure".  Anyone interested in breaking in has only
> to try out a bag of tricks until he hits that forgotten 1%.  OTOH, a
> 99% well maintained car is very nearly indistinguishable from a 99.9%
> well maintained car.

I'm afraid I must disagree:  I would find a system with 1% risk much
more preferable than 60% risk, especially if the vulnerabilities are
remote-root network exploits.

You appear to be using an absolute model of "secure" vs. "unsecure"
in which you claim 1% risk is the same as 60% risk.  In that case,
using your model, your Linux system is _insecure_ _right_ _now_, and
there's nothing you can do about it.  (PUIS 2nd ed., pg. 34 -- trust
is introduced on page 26.)

So while you are free to use whatever model you want, most of us are
interested in practical applications of computer security, and that
means risk assessment and mitigation ("less secure" vs. "more secure",
not "unsecure" vs. "secure").

> Hmm.  An admin cannot secure something he does not understand.

Admins can certainly mitigate system risks without understanding the
details.  For instance, if an admin gets email from a vendor telling
her to "upgrade Sendmail/Perl/Whatever _now_", it doesn't require a
lot of security savvy to figure out a) their system's risk of
compromise has increased, and b) it will continue to increase in
a time-dependent fashion until they upgrade.[1]

Of course, it's _better_ if folks have a solid understanding of all
nuances of computer security -- but for folks just starting out with
Linux, who want to improve their systems' security posture, it
doesn't seem appropriate to throw them a 900-page tome and tell them
their system "can't be secure" unless they understand it.  (Not
only is it wrong, they'll _learn_ it's wrong when they get to
page 34. ;)

Again, the goal here is to mitigate risks.  I can't see how a
well-written Linux security tutorial wouldn't improve security within
the Linux community.  It might not cover all the bases (and it should
be up front about that), but heck, neither does PUIS (which it freely

Further, I see that seifried's page already includes PUIS in the
"Other Documents / Books" section -- that seems fair, since
PUIS encourages its readers to examine OS-dependent documentation.
Mr. seifried's paper seems to fit that category.

Finally, let's refine what we're talking about:

>> The only thing I can see coming out of a "checklist" security setup
>> is a false sense of security.

IMHO, this is incorrect.  A "checklist", or tutorial, would help
new users mitigate risks -- and the resulting improved security is
real, not imagined.

>> The moment poor Joe User does something unanticipated or tricky,
>> he'll be both unaware of his problem and unable to handle it
>> once/if detected.  Conversely, a clueful user stands a chance at
>> anticipating problems and being able to handle them.

While that may be the case, I think it would be better to
simply warn the tutorial's readers that this could be a danger,
rather than abandon the tutorial.

Mr. seifried, good luck with your book.  Please make it a _good_
book.  :)


[1]  As exploit information propagates through the
grapevine, more and more people may potentially attack your system,
which increases the risk of compromise.  This seems to be the
discrete case of a general security principal, where risk can be
expressed as a function of time.

For instance, smart Linux admins pipe the Linux-alert list to their pagers
-- early warnings reduce risk, since not as many people have
heard about the vulnerability.

The general case:  "Security through obscurity is not security."

If someone has heard of a discussion of "Security through
obscurity" as a function of time, I'd really appreciate a
pointer.  Thanks.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]