Date: Fri, 21 Feb 2003 11:44:22 -0800 From: "Crist J. Clark" <crist.clark@attbi.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: 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: <20030221194422.GD90209@blossom.cjclark.org> In-Reply-To: <p05200f0dba7b6c5f4cb2@[128.113.24.47]> References: <200302210528.h1L5SS0H092948@repoman.freebsd.org> <p05200f0dba7b6c5f4cb2@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 21, 2003 at 12:54:04AM -0500, Garance A Drosihn wrote:
> At 9:28 PM -0800 2/20/03, Crist J. Clark wrote:
> >cjc 2003/02/20 21:28:28 PST
> >
> > Modified files:
> > sys/netinet in_pcb.c
> > Log:
> > The ancient and outdated concept of "privileged ports" in UNIX-type
> > OSes has probably caused more problems than it ever solved. Allow the
> > user to retire the old behavior by specifying their own privileged
> > range with,
> >
> > net.inet.ip.portrange.reservedhigh default = IPPORT_RESERVED - 1
> > net.inet.ip.portrange.reservedlo default = 0
> >
> > Now you can run that webserver without ever needing root at all. Or
> > just imagine, an ftpd that can really drop privileges, rather than
> > just set the euid, and still do PORT data transfers from 20/tcp.
>
> 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, I though that locking ports > 1023 might be a feature people
want. But if not, we could fix > 1023 always to be unprivileged, and
then,
# sysctl net.inet.ip.portrange.reservedhigh=79
# sysctl net.inet.ip.portrange.reservedlow=81
Would do what you want. In the current implementation this would lock
out the whole 81-65535 range, which you probably don't want.
> Would that be hard to implement? Maybe even tied to a userid?
> (so any process from a given user could bind to the port, but not
> any process from any user). All this change effects is whether
> the bind() will succeed, right? Maybe have the exception tied to
> the existence-of and access-to some specific file?
>
> [apologies if this was discussed somewhere and I missed it...]
It has been discussed many times before, but not recently. I just
decided to up and make the change without getting bogged down in
feature requests or "maybe it'd be cooler if we..." suggestions. As I
mention elsewhere in the thread, I Just Did It(tm) after getting fed
up with some security problems on other systems and redirecting my
frustration to someplace where I could make some small difference.
Your feature requests have come up before. They are not horrendously
difficult to implement, but they are not easy. Do we want to allow
access to a fixed number of ports? A fixed number of ranges? A dynamic
number of ports or ranges? Assign a uid allowed to open all, or assign
on a one-by-one basis? How do we store this in the sysctl tree? Or
maybe this is a job for MAC tools? As for connecting it to the
existence of some file... That's new and pretty elaborate sounding.
Once you answer all of those (and everyone still will not be happy),
you can start to write code. The change I made borders on trivial from
a coding perspective. It was low cost and low risk with respect to the
functionality it provides. IMHO, if someone can come up with a slick
way to dynamically assign port-uid pairs that is not overly
complicated (i.e. potentially buggy) or expensive, lets get it in the
tree. Anything more complicated than that should be implemented in a
MAC framework.
If someone wants to add these and other features and run over my
changes, go ahead. I only ask that you make it quick so that the
handful of people who actually are going to use this don't get used to
'net.inet.ip.portrange.reserved{high,low}' just in time for them to
disappear.
PS: Note the small misspelling in my commit message, 'reservedlo'
should be 'reservedlow.' Not worth a forced commit since I will
document it properly in ip(4).
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
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?20030221194422.GD90209>