Date: Thu, 16 Dec 1999 16:03:04 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: freebsd-security@FreeBSD.ORG, asami@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) Message-ID: <Pine.BSF.3.96.991216154939.26813L-100000@fledge.watson.org> In-Reply-To: <99Dec17.073616est.40329@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Let me introduce my response by making excuses: I spit out my suggestions
off the top of my head, and was more interested in suggesting a direction
than a specific set of changes. The direction, needless to say, is
mandating the identification of code that introduces greater risk for
consumer. Please see my rather extensive philosophical banter post that
went to bugtraq a week or two ago, and was forwarded to -audit shortly
afterwards. All of the suggestions you make are good ones, and I'll leave
to those more familiar with the ports system determining the correct
solution for their needs.
On Fri, 17 Dec 1999, Peter Jeremy wrote:
> I've copied to Asami-san since I believe his input is critical to any
> changes to the ports mechanism.
>=20
> On 1999-Dec-17 05:56:26 +1100, Robert Watson <robert@cyrus.watson.org> wr=
ote:
> >Yup, it's d=E9j=E0 vu all over again. If you want a heavy-handed securi=
ty
> >approach, here's how you do it. Define two new Makefile ports variables=
:
> >
> >HAS_MISC_SET_ID=3D {yes,no}
> >HAS_ROOT_SETUID=3D {yes,no}
>=20
> 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:
>=20
> HAS_GAMES_SETUID=3D {yes,no}
> IS_UNSAFE=3D {yes,no,maybe}
I agree. MISC is far too broad; I'd suggest also a HAS_KMEM_GID, another
common choice, such as for utilities like lsof. I'm still a little
critical of the idea of having a games gid, and sgid games, in the first
place :-).
> >Starting today, warn all ports maintainers that their ports must (ideall=
y
> >correctly) define these variables for all of their ports.
>=20
> 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).
Ok, sounds good. I was vaguely aware of the ports freeze, as Warner
referenced it as a reason for delaying the patch, but am not heavily
involved, except as a consumer, with the ports development.
> > In two weeks,
> >any port that doesn't define both variables is marked as broken.
>=20
> 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).=20
I chose two weeks as an arbitrary but soon date. People are installing
ports and packages daily, and they are rebuilt regularly and made
available fro download. My goal was to set a bound that allowed port
developers with immediate interest in maintaining their ports to have time
to make the change, but also sufficiently short that we would reduce the
risk for the ports consumers, the real target for security improvements.
Out there, right now, are lots of machine maintainers that have security
holes in their machines. This is *our fault*, and we do them no favor by
not disabling code that we cannot be sure is safe. How about a warning
then--if the Makefiles don't have appropriate *id tags by two weeks from
now, Make will warn that the code has not been categorized and require
"make OVERRIDE_POSSIBLE_SECURITY_PROBLEM=3Dyes" to build the code. This
means the ports are still available, but raises a flag for consumers.
I'm open to many varations on the theme, but think a relatively close
deadline for port classification is important. See my comments below on
the auditing issue.
> >We then have an effective and mandated list of ports making use of set?i=
d
> >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.
>=20
> 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 ...'?
It's not clear to what extent the auditing team should or should not be
responsible for third party code--it's not in the audit teams mandate to
go beyond the base source tree, and there's lots for them to do there. On
the other hand, it makes sense to do a first path elimination of ports
that are clearly insecure or have privileges elevated beyond reason.
Eliminate could still imply available, just with a warning and/or
confirmation. Part of the "bugtraq" problem phenomena is that we do not
clearly identify which code we are and are not willing to accept
responsibility for. Right now there are posts going up saying "FreeBSD
security hole" because just before packages installation, we don't flash
up a "This is third-party unaudited code message". We know it's
third-party and unaudited, but to be honest, we don't make that clear to
consumers who may not have picked it up along the way.
Again, I refer you to my earlier post talking about some of the issues. I
think, if possible, it would be desirable for us to have a way of
rejecting some ports without implicitely improving the rest: a real
security analysis is the responsibility of the application developer, not
of the porter, nor us.
> Lest the above sound too negative, I think Robert's approach is a good
> idea. I'm just not sure about the details.
I agree :-). The details are probably all wrong, but I do think the
approach is the correct one: to place some onus on ports developers to
take immediate action to identify risky code and permissions, and in the
long run to try to screen ports that are particularly relevant to us (such
as, say, apache) and run with privilege. It's also our responsibility to
identify risks to users of the system in clear and easily understood ways:
this helps us by making it so that we don't take the fall (and get toasted
on bugtraq), and it helps the consumer by allowing them to make informed
decisions about risks they take on by using particular packages, ports,
etc.
Robert N M Watson=20
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
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?Pine.BSF.3.96.991216154939.26813L-100000>