Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Dec 2002 12:09:20 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        dillon@apollo.backplane.com
Cc:        sam@errno.com, mux@FreeBSD.ORG, obrien@FreeBSD.ORG, current@FreeBSD.ORG
Subject:   Re: ipfw userland breaks again.
Message-ID:  <20021215.120920.131103264.imp@bsdimp.com>
In-Reply-To: <200212151903.gBFJ3abr081740@apollo.backplane.com>
References:  <200212151826.gBFIQMpo081407@apollo.backplane.com> <20021215.115657.90648628.imp@bsdimp.com> <200212151903.gBFJ3abr081740@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200212151903.gBFJ3abr081740@apollo.backplane.com>
            Matthew Dillon <dillon@apollo.backplane.com> writes:
: 
: :
: ::    This is complete BULLSHIT, Warner.  
: :
: :Your attitude it totally unacceptible.  Learn to play well with
: :others, or get the fuck out of the project.
: :
: :I am *NOT* blocking you.  I'm telling you you need to get the SO's
: :sign off to make sure that there isn't a security issue because the
: :current defaults were set by the so.  If you don't like that, then I
: :suggest that you get over yourself and find someplace else to play.
: :
: :Warner
: 
:     This is not a security issue.  Why do you think it is?  How is
:     'ipfw unbreak' any different from 'ipfw add 2 allow all from any to any'?
:     (Other then the fact that unbreak is immune from API changes).
: 
:     Have you even bothered to read the patch?

Yes, I have.  It potentially has security implications because it is a
security part of the system.  That's why I think it would be valuable
to get the SO's input on what you are doing.  I've read the patch.  It
makes it possible with one ioctl to turn off the firewall to allow you
to use the system.  That needs careful reviewed.

In fact, it has one flaw.  You'll find on lines

	/*
	 * Disallow modifications in really-really secure mode, but still allow
	 * the logging counters to be reset.
	 */
	if (sopt->sopt_name == IP_FW_ADD ||
	    (sopt->sopt_dir == SOPT_SET && sopt->sopt_name != IP_FW_RESETLOG)) {
#if __FreeBSD_version >= 500034
		error = securelevel_ge(sopt->sopt_td->td_ucred, 3);
		if (error)
			return (error);
#else /* FreeBSD 4.x */
		if (securelevel >= 3)
			return (EPERM);
#endif
	}

which you haven't changed.  This strikes me as a danger operation to
allow in high security mode, so there likely needs to be some changes
assocaited with the above lines (like an || sopt->sopt_name ==
IP_FW_UNBREAK in the above).  Otherwise, an attacker would be able to
turn off the ipfw stuff at a high security level.

I'm not trying to get in your way Matt, I'm just saying that there
needs to be a little discussion on this kludge if you aren't going to
fix the real, underlying problem,  ok?

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021215.120920.131103264.imp>