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

[R E Wolff BitWizard nl (Rogier Wolff)]

Scott Doty wrote:
> 
> 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.

For me, closing off telnet because of the plain-text passwords, but
allowing FTP is something that is nonsensical. Others argue that it
makes stuff just a teeny bit more secure. 

Some say they want a virtual interface configured for the IP of a
machine that is trusted and "down". I say that knowing someone spoofed
your IP and was able to login as root is not useful on a cluster of 80
machines with too little personell to reinstall them all. 

So, in both these examples some would say it makes it just a bit more
secure and every little bit helps, while others (and I agree with this
group) say that sometimes the improvement doesn't really help enough
to make a difference. 


> 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").

The problem is that if you give directions like

       edit /etc/inetd.conf and put a "#" before "finger". 

you'll have a slighly more secure site, but for how long? You're
helping to create a set of machines that are closed off for a specific
set of services/holes, but they may remain open on others. As long as
those doing the daily maintenance don't actually understand what they
are doing, you can consider their machines wide open.

The person writing the book or keeping the web site uptodate suddenly
has the burdon of having to update it within hours from publication
on bugtraq. No more vacations. New editions for the book every week. 

To get people going, a few remarks like "you can disable services by
removing them from inetd.conf, but make sure that your system doesn't
start a permanently running deamon from the boot scripts" will help. 

However besides that, you need to create an understanding in the
audience. Line-by-line howtos don't help if they are a week
out-of-date.


					Roger. 

-- 
Actor asks a collegue: "To what do you owe your success in acting?"
Answer: "Honesty. Once you've learned how to fake that, you've got it made."
-------- Custom Linux device drivers for sale! Call for a quote. ----------
Email: R E Wolff BitWizard nl || Tel: +31-15-2137555 || FAX: +31-15-2138217