Date: Sat, 30 Sep 2000 11:44:19 -0700 From: Jordan Hubbard <jkh@winston.osd.bsdi.com> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: Roman Shterenzon <roman@xpert.com>, Kris Kennaway <kris@FreeBSD.org>, security@FreeBSD.org Subject: Security and FreeBSD, my overall perspective Message-ID: <2376.970339459@winston.osd.bsdi.com> In-Reply-To: Message from "Brian F. Feldman" <green@FreeBSD.org> of "Sat, 30 Sep 2000 11:38:36 EDT." <200009301538.e8UFcb538293@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
perfection. Does that mean we should stop shipping FreeBSD in binary
form? Of course not, and I daresay that FreeBSD and any other Unix
system comes with an explicit "warning label" telling the administrator
that they'd better know what the hell they're doing before putting a box
on the network.
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!").
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:
(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").
(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.
(c) Start doing meaningful auditing of code and stop chasing
various illusions of security. By this, I mean not just
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. They may lie completely
outside the area of buffer overflows (there being many many
ways to write insecure code) or they may be very specific
buffer overflows, where the user has an actual opportunity to
control the data going in. Data which is simply moving around
internally and never has the opportunity to overflow under
user control is not data you have to worry too much about.
In fact, in some cases you might prefer the code to
dump core and actually expose the bug rather than just
silently truncating data and producing rather more
erroneous results.
- Jordan
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?2376.970339459>