Date: Fri, 17 Dec 1999 07:43:29 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: freebsd-security@FreeBSD.ORG, asami@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) Message-ID: <99Dec17.073504est.40321@border.alcanet.com.au> In-Reply-To: <Pine.BSF.3.96.991216135055.26813G-100000@fledge.watson.org>; from robert@cyrus.watson.org on Fri, Dec 17, 1999 at 05:56:26AM %2B1100 References: <14425.12637.308602.637788@anarcat.dyndns.org> <Pine.BSF.3.96.991216135055.26813G-100000@fledge.watson.org>
index | next in thread | previous in thread | raw e-mail
I've copied to Asami-san since I believe his input is critical to any
changes to the ports mechanism.
On 1999-Dec-17 05:56:26 +1100, Robert Watson <robert@cyrus.watson.org> wrote:
>Yup, it's déjà vu all over again. If you want a heavy-handed security
>approach, here's how you do it. Define two new Makefile ports variables:
>
>HAS_MISC_SET_ID= {yes,no}
>HAS_ROOT_SETUID= {yes,no}
I think `MISC' is too general. I'd split it into `games' (since there
seems to be a general concensus that setuid-games is the least
unsavoury way to handle machine-wide high-scores files) and `misc' (in
case a game wants to be setuid something else - though I can't think
of any justification for other UIDs). We also need an `unsafe' marker
to support the install alarms. How about adding the following as
well:
HAS_GAMES_SETUID= {yes,no}
IS_UNSAFE= {yes,no,maybe}
>Starting today, warn all ports maintainers that their ports must (ideally
>correctly) define these variables for all of their ports.
The middle of a ports freeze is a bad time for this. (Though, if the
infrastructure was ready at the end of the ports freeze, it would
make a clear transition point).
> In two weeks,
>any port that doesn't define both variables is marked as broken.
Two weeks might be a bit short. I don't believe there's any pressing
need for this (the critical deadline to meet would be the next
CD-ROM pressing - which is now several months off). I would think
that a month might be better (Asami-san would have a better idea of
a reasonable period).
>We then have an effective and mandated list of ports making use of set?id
>binaries. Each one of these ports undergoes a security view by the
>auditing team--not to fix bugs, just to identify whether the source code
>is prone to bugs (extensive use of string functions in unsafe ways, etc)
>-- a twenty minute thing.
Doesn't this just build a false sense of security? A guick-and-dirty
review is guaranteed to miss things (or rather, miss more things than
a thorough review), as well as generate lots of false positives. How
do you placate a developer/maintainer whose cherished port has been
unjustly given an "unsafe" tag because the reviewer couldn't spend the
time to confirm that every code path into a potentially unsafe function
included the validation necessary to make the function safe? How do we
respond to the (inevitable) BUGTRAQ posts which state that `the FreeBSD
Security Auditing Team gave the program a clean bill of health but
missed the following security hole ...'?
Lest the above sound too negative, I think Robert's approach is a good
idea. I'm just not sure about the details.
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Dec17.073504est.40321>