From owner-freebsd-arch@FreeBSD.ORG Wed May 27 18:05:02 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8884F10656BB for ; Wed, 27 May 2009 18:05:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 68D538FC19 for ; Wed, 27 May 2009 18:05:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B1FD3D5CC3; Wed, 27 May 2009 11:05:00 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id C2D0E2D6016; Wed, 27 May 2009 11:04:58 -0700 (PDT) Message-ID: <4A1D80CA.4020702@elischer.org> Date: Wed, 27 May 2009 11:04:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20090526135547.GE1491@garage.freebsd.pl> <4A1CD562.9040706@elischer.org> <20090527065121.GD4204@garage.freebsd.pl> In-Reply-To: <20090527065121.GD4204@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: adrian@FreeBSD.org, trasz@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: IP_NONLOCALOK improvements. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:05:04 -0000 Pawel Jakub Dawidek wrote: > >>> All in all I went with rename to make at least similar to OpenBSD's >>> option. I left it as IPPROTO_IP option: IP_BINDANY. >> well, ok, a rose by any other name would smell as sweet. >> As I said I was not aware of the OpenBSD code, but I don't like >> their choice of name as it doesn't really describe what it does. > > I changed the name just to be more similar to OpenBSD's (and BSD/OS') so > one can more easly find it by grepping. I'm really fine with any name. > >>> I added new privilege - PRIV_NETINET_BINDANY, because we do have to >>> check for privilege before allowing to use it. are we sure we want to make a whole PRIV just for this function? >> I am not sure about this. if a system has this enabled then I presume >> it is a special system and not a generally available time-sharing system. >> >> How do you allow a process to have this privilege? are you forcing >> them to be root for now? > > Our current privilege model is that we have fine-grained privileges in > the kernel, but those are not _yet_ exposed to userland. All privileges > defined in sys/priv.h are available for unjailed root and some (take a > look at prison_priv_check() function) for jailed root. when we have vimage, this may be required in some vimages and not others.. the priv should be inherrited but gated on the new jail.. in other words, when yo create a child jail, it can do it if: 1/ the parent can do it AND 2/ the parent allows the child to do it. > > Today this new privilege will only be available for unjailed root. > > At some point we will grow possibility to selectively add/remove > privileges just like Solaris, but we can't do that now. > >>> I removed kernel option to enable it, I see to reason not to have it in >>> GENERIC. >> Because it adds complexity and because some people do not want it even >> possible. >> You are eneabling NON-standard, (in fact "Standard-ignoring") >> behaviour. >> >> >>> I also removed sysctl to enable it - we have privilege for limiting its >>> use. >> I disagree very strongly about this one. I would liek to >> 1/ have to explicitly compile in thi snon standard behaviour and >> >> 2/ turn it on >> >> before we start doing this. >> >> >> I know how useful this is to have, (from my own experience) >> but feel strongly that this is pretty bad behaviour for most systems >> and can facilitate all sorts security worries. > > Well, this is behaviour is similar to adding an IP address to an > interface and binding to that address. There is even no securelevel that > denies modifing interfaces, so in my opinion if one needs to explicitly > ask for this to be enabled for a socket and one needs a special > privilege to do it, it should be enough protection to make user's live a > bit less complex by not requiring kernel recompilation and sysctl > modification. > > I'm not sure if this was on purpose, but currently even unprivileged > user can use this functionality if the sysctl is on, which I find hard > to accept. Having this always enabled and requiring a privilege is IMHO > more secure than allowing anyone to use it once the sysctl is on. > But again, combining the two (privilege and sysctl) is redundant IMHO. it was on purpose as it was assumed, as I said, that anyone compiling it in would be creating a special "appliance" kernel and be fully in charge of the machine. > > If it doesn't convince you and I also don't feel convinced we need to > wait for more votes:) I can live with having it there by default in GENERIC, but I'm not sure I don't still want to be able to remove it.. the sysctl could go , but I felt I wanted a way for the admin to disble it on a system if it shared a kernel with other systems that need it. i.e. if it's in GENERIC, then I think the admin should be able to stop it from being available. >