Date: Thu, 16 Dec 1999 16:23:17 -0500 (EST) From: Spidey <beaupran@iro.umontreal.ca> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: Robert Watson <robert+freebsd@cyrus.watson.org>, freebsd-security@FreeBSD.ORG, asami@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) Message-ID: <14425.22597.651762.236431@anarcat.dyndns.org> References: <14425.12637.308602.637788@anarcat.dyndns.org> <Pine.BSF.3.96.991216135055.26813G-100000@fledge.watson.org> <99Dec17.073504est.40321@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Big Brother told Peter Jeremy to write, at 07:43 of December 17:
> 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=
> wrote:
> >Yup, it's d=E9j=E0 vu all over again. If you want a heavy-handed se=
curity
> >approach, here's how you do it. Define two new Makefile ports varia=
bles:
> >
> >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 ther=
e
> seems to be a general concensus that setuid-games is the least
> unsavoury way to handle machine-wide high-scores files) and `misc' (i=
n
> case a game wants to be setuid something else - though I can't think
> of any justification for other UIDs).
Well, there's "postfix", "mysql", "bind", to name a few..=20
> 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}
We may also take into account setgid, while we're at it...
So we would get:
HAS_GAMES_SETUID=3D {yes,no}
HAS_GAMES_SETGID=3D {yes,no}
HAS_ROOT_SETUID=3D {yes,no}
HAS_MISC_SETUID=3D {yes,no}
HAS_MISC_SETGID=3D {yes,no}
IS_UNSAFE=3D {yes,no,maybe}
We might as well put it like:
HAS_SETUID=3D {root, games, misc, ...}
HAS_SETGID=3D {games, wheel, misc, ...}
but I don't know how that would fit in FBSD's Makefiles mechanisms...
=20
> >Starting today, warn all ports maintainers that their ports must (id=
eally
> >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).
Indeed. That would be a great feature for 3.5! :)
=20
> > 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
Indeed. I agree that our primary concern with that is the CDROMs
release, as the ports users are generally more aware of the
consequences of using the ports...
[snip]
> Lest the above sound too negative, I think Robert's approach is a goo=
d
> idea. I'm just not sure about the details.
I also really think that this is a wonderful idea. We can take some
time to think about it.=20
The AnarCat
--=20
Si l'image donne l'illusion de savoir
C'est que l'adage pretend que pour croire,
L'important ne serait que de voir
Lofofora
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?14425.22597.651762.236431>