Date: Thu, 28 May 2009 14:56:12 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: trasz@FreeBSD.org, adrian@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: IP_NONLOCALOK improvements. Message-ID: <alpine.BSF.2.00.0905281453440.32501@fledge.watson.org> In-Reply-To: <4A1D80CA.4020702@elischer.org> References: <20090526135547.GE1491@garage.freebsd.pl> <4A1CD562.9040706@elischer.org> <20090527065121.GD4204@garage.freebsd.pl> <4A1D80CA.4020702@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 May 2009, Julian Elischer wrote: >>>> 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? We have lots of privs, and in fact that's the point of privs: they should narrowly describe a specific privilege so that granting that privilege doesn't (generally) imply the granting of other privileges. Some privileges are necessarily more broad (for example, privilege to enable I/O port access from userspace implies all other privileges), but mostly this is not true of access control privileges such as this one. >>> 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. The eventual intent is to support privilege masks in FreeBSD, which would include a jail cap on privileges granted in the jail, as well as the ability to assign more specific privilege sets to specific non-root processes. I had hoped to get this done for FreeBSD 8.0, but due to other obligations, that hasn't happened. Perhaps if it goes well, we'll get one for 8.1 or 8.2. The main priority in doing this is doing it safely, since there are lots of worked examples in how not to get it right. Robert N M Watson Computer Laboratory University of Cambridge > >> >> 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. > > > >> > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0905281453440.32501>