Date: Sat, 30 Sep 2000 12:22:17 -0700 From: Kris Kennaway <kris@FreeBSD.org> To: Jordan Hubbard <jkh@winston.osd.bsdi.com> Cc: "Brian F. Feldman" <green@FreeBSD.org>, Roman Shterenzon <roman@xpert.com>, Kris Kennaway <kris@FreeBSD.org>, security@FreeBSD.org Subject: Re: Security and FreeBSD, my overall perspective Message-ID: <20000930122217.A51270@freefall.freebsd.org> In-Reply-To: <2376.970339459@winston.osd.bsdi.com>; from jkh@winston.osd.bsdi.com on Sat, Sep 30, 2000 at 11:44:19AM -0700 References: <green@FreeBSD.org> <2376.970339459@winston.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 30, 2000 at 11:44:19AM -0700, Jordan Hubbard wrote:
> > Who has the motivation (of any type) to find and fix the likely hundreds of
> > security problems left, though?
>
> Again, the word is "likely" here and I could just as easily say that
> parts of what we currently ship in the bindist are "likely" to have
> bugs because past experience has shown this to be true and software is
> always an exercise in compromise between time/resources available and
You could say that, but you'd be making an unsupported claim of
likelihood. You are confusing "probable" with "well, we can't rule it
out", which of course applies to 99% of all code. Not so for what I
did with pine: it's had two problems reported in the past few weeks,
and a look at the code shows that because of the offensive (as opposed
to defensive) way it's written it is very likely that more problems OF
THE SAME KIND lurk beneath the surface. Given this, I have something
concrete to point to when I say problems are likely.
> Some people have also cited arguments that if we don't protect the
> administrators from their own incompetence, they'll feel betrayed by
> FreeBSD and go run Windows or something (which has an excellent
> track-record for security). I also think that's a ridiculous argument
> since, if followed to the letter, can only lead to situations like we
> have in society today where every activity which could be even
> remotely considered dangerous is either forbidden or comes with
> warning labels 10 inches high, right down to the hot coffee ("WARNING:
> This is HOT COFFEE. DO NOT POUR IT INTO YOUR CROTCH!").
Well, thats NOT what I meant, and you're reading a different
interpretation into my words. Read on:
> This is Unix. You're supposed to have at least a minimum level of
> clue in order to use it and dumbing it down so that this is no longer
> necessary would not constitute an advance. If we want to do something
> useful when it comes to all-around security, we should:
Okay, quick show of hands. How many people blindly trusted pine before
this week? How many people would pick up a copy of fsdb(8) and/or
ipfw(8) and feel blindly confident they know how to use it properly
without screwing themselves up?
There are three points at work here:
1) Tools which are documented as being dangerous or which can
compromise your security fall into the "well, it's your own fault
category".
2) Almost no-one thinks about client applications as a security
risk. Most of us are trained to think of servers as potential points
of weakness, but client applications like pine and netscape get little
attention.
3) Theres nothing an end-user can do to protect himself with certainty
from pine, short of "don't read mail with it". Again, this is a
statistically uncertainty given that I havent spent days of my life
doing a thorough code audit, but I'm willing to put money on the
existence of further vulnerabilities in the code.
What I have done (and will finish doing when I add the install-time
security warning) is move pine into category 1.
> (a) Continue to issue advisories for both the "system" and for
> ports so that people are properly informed about
> vulnerabilities when they're actually found (and not just
> "suspected").
No-one's breathed a word about changing this. However, I will be
adding a cautionary warning on the next pine advisory, dealing with
the currently known remotely exploitable buffer overflow, that it is
the opinion of the security officer that there are probably further
problems waiting to be discovered.
> (b) Add a new field to the ports infrastructure which indicates
> level of "trust" the project/security people have in that
> port. E.g. instead of having one big knob rather off-puttingly
> labelled 'FORBIDDEN', have a 'TRUST' or 'SECURITY_LEVEL' variable
> which goes from 1 to 10. Then the ports infrastructure can, if
> it wishes to, issue warnings of varying severity based on the
> trust level.
I've thought about this, but it needs someone to implement it, so we
have to work with existing tools in the meantime.
> (c) Start doing meaningful auditing of code and stop chasing
> various illusions of security. By this, I mean not just
Waitasec, what do you mean "start"? FreeBSD is basically the only
operating system project which *is* auditing this kind of code
(impression based on the security advisory output of all of the other
OSes).
> blindly grepping around and assuming one is doing something
> useful by replacing certain functions with ones which
> bounds-check but actually *reading* the code and seeing
> where the genuine flaws lie.
And again, there was more than blind grepping involved here with
pine. But it's simply not something I have the time, nor the
inclination to correct, the code misdesign being too endemic and the
required time investment being singularly massive. Patches by anyone
else will be gratefully accepted, but a warning about the trust level
of the code will remain in the meantime.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000930122217.A51270>