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>
index | next in thread | previous in thread | raw e-mail
--- 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.
>
> 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).
Well, there's "postfix", "mysql", "bind", to name a few..
> 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}
We may also take into account setgid, while we're at it...
So we would get:
HAS_GAMES_SETUID= {yes,no}
HAS_GAMES_SETGID= {yes,no}
HAS_ROOT_SETUID= {yes,no}
HAS_MISC_SETUID= {yes,no}
HAS_MISC_SETGID= {yes,no}
IS_UNSAFE= {yes,no,maybe}
We might as well put it like:
HAS_SETUID= {root, games, misc, ...}
HAS_SETGID= {games, wheel, misc, ...}
but I don't know how that would fit in FBSD's Makefiles mechanisms...
> >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).
Indeed. That would be a great feature for 3.5! :)
> > 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).
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 good
> 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.
The AnarCat
--
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14425.22597.651762.236431>