Date: Fri, 21 Feb 2003 18:31:22 +0100 From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Garance A Drosihn <drosih@rpi.edu>, "Crist J. Clark" <cjc@FreeBSD.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet in_pcb.c (priv ports) Message-ID: <4B77CF28-45C2-11D7-9535-000393754B1C@vangelderen.org> In-Reply-To: <Pine.NEB.3.96L.1030221101604.12840A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, Feb 21, 2003, at 16:18 Europe/Amsterdam, Robert Watson wrote: > > On Fri, 21 Feb 2003, Garance A Drosihn wrote: > >> While this can be useful, it would be nice if there was also an >> exception-mechanism, instead of just a "lo" and "high" value. If I >> want >> to run a web server without needing root, then I'd like to allow port >> 80, and not an entire range of 0-80 or 80-1024. > > Well, if you want, you could combine these twiddles with a custom MAC > module that checks the arguments to bind(), connect(), etc, and has an > access control list regarding who can use which ports. Note that ipfw > doesn't prevent you from binding the ports and therefore excluding > other > use, it just prevents certain classes of packet use. There are > actually > at least two functions of the reserved port behavior -- first, the > historic "we know root must have authorized the sending of these > packets", > and second, the "prevent joe user from offering official services > without > appropriate privilege". Aspects of the second part are still > important, > so unless you have only trusted users on your web server machine, you > might want access controls to prevent inappropriate users from starting > web servers next time you restart your web server and the ports are > temporarily unbound. Even if you only have trusted users on your machine the extra layer of defense provided by access controls can have benefits: defense in depth. Very useful when one of those trusted users turns malicious (for instance because one of his daemons is compromised). In the meantime however, allowing an extension of the original, overly restrictive feature provides some relief. For a large class of well-designed network protocols (including SSH) the associated risk is limited to mere Denial of Service; Annoying but preferred over a potential root compromise. And given that they are optional *and* disabled by default, the new sysctls fit the FreeBSD mantra of "providing tools, not policy". Cheers, -J To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B77CF28-45C2-11D7-9535-000393754B1C>