Date: Wed, 27 May 2009 08:51:21 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: adrian@FreeBSD.org, trasz@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: IP_NONLOCALOK improvements. Message-ID: <20090527065121.GD4204@garage.freebsd.pl> In-Reply-To: <4A1CD562.9040706@elischer.org> References: <20090526135547.GE1491@garage.freebsd.pl> <4A1CD562.9040706@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 26, 2009 at 10:53:38PM -0700, Julian Elischer wrote: > Pawel Jakub Dawidek wrote: > >Now that we have IP_NONLOCALOK IP socket option (which is something I > >need a lot for my company's stuff) I started to hack on it a bit. > > > >OpenBSD has SO_BINDANY SOL_SOCKET option for some time now. So first of > >all I wanted to do the same for FreeBSD. Unfortunately we ran out of > >space in so_options - it is u_short and all possible values are already > >taken. As a side note there is SO_NO_DDP option that is used only in > >cxgb driver and nowhere else. This seems like a waste of very important > >bit (sonner or later someone will need yet another socket option). >=20 >=20 > when I wrote the NONLOCAL stuff I was abstracting functionaity that > IronPort have in their system. What they have though can not be > turned off or disabled. That part was added just for the public > version. I didn't know of the OpenBSd code or I might have tried to > make it compatible. [...] I know that, Julian, and forgive me if it sounded like an accusation. I also wasn't aware that OpenBSD (and FreeBSD too) has it until yesterday:) I'm very grateful that you did the work, because now I can simplify at least three company's project. All I'm trying to do is to improve it, not to nitpick. > [...] The test is done in the IP code so therefore it=20 > was easist to make it an IP option, though I implement it in a > slightly non-IP specific manner. >=20 >=20 > > > >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. >=20 > 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. >=20 > I am not sure about this. if a system has this enabled then I presume=20 > it is a special system and not a generally available time-sharing system. >=20 > How do you allow a process to have this privilege? are you forcing=20 > 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. 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. >=20 > Because it adds complexity and because some people do not want it even=20 > possible. > You are eneabling NON-standard, (in fact "Standard-ignoring") > behaviour. >=20 >=20 > > > >I also removed sysctl to enable it - we have privilege for limiting its= =20 > >use. >=20 > I disagree very strongly about this one. I would liek to > 1/ have to explicitly compile in thi snon standard behaviour and >=20 > 2/ turn it on >=20 > before we start doing this. >=20 >=20 > 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. If it doesn't convince you and I also don't feel convinced we need to wait for more votes:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --L6iaP+gRLNZHKoI4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKHOLoForvXbEpPzQRAr9AAJ9nT7n1W0lUvloQoMBzxHbxcnLwJQCZAV7r NXU2WYEdsLJHsYaKVT0eS5o= =vxy2 -----END PGP SIGNATURE----- --L6iaP+gRLNZHKoI4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090527065121.GD4204>