Re: Liberating locked up ports
Re: Liberating locked up ports
- Subject: Re: Liberating locked up ports
- From: "Sean Bullington" <email@hidden>
- Date: Wed, 29 Jan 2003 00:40:12 -0600
I actually took place in a debate on this list a while ago, where I
argued *for* having the reserved ports. My logic was:
"Everyone expects servers that are running on those ports to be
legitimatly installed and run by the server's administrator, and not
from arbitrary users."
IE: If a webserver was running on ports 80/443 on say, a bank website,
and the server could be crashed and another one could be started on that
port by a non-root user (who hadn't owned the box, just had an account
and had been able to crash the web server) then that non-root user could
easily start stealing information that normally would only go to the
'trusted' webserver. (Yes yes I understand that you'd have to have an
account, it would be most likely in a server environment, you'd have to
have a crashable webserver, etc. etc. but it's just an example.)
IIRC, at that time Quinn was arguing that there really wasn't a good
reason for the 1024 port restriction... and since that time I've come to
agree with him, especially in the case where you aren't using the box as
a server, but more as a workstation/desktop.
It seems like the *best* way to fix the problem would be to have (as you
mentioned) a configuration mechanism to specify which users could bind
to which ports. This would place the burden of security on the
administrators of the boxes, which some people may argue would be less
secure. However, you can only babysit admins to a certain point...
One possible workaround for now though could be port redirection. For
example, in FreeBSD, I can use IPFilter/IPNat to add rules that will
redirect port 21 (for FTP) to a particular ephemeral port. Then the FTP
server starts up, binds to that ephemeral port, and any requests that
come to port 21 on the box are redirected to the port the FTP server is
actually bound to. The FTP server therefore never needs to run as root,
yet can still 'listen' on port 21. All the work for doing the
transferring of data between ports is done by the kernel, and thus you
don't have a suid app sitting around. This doesn't guarantee that
someone else won't be able to crash my FTP server and start one bound to
the same ephemeral port, but hey, it's only a workaround :)
I'm not sure if there's a way to do this with OSX or not, and it
probably would be a pain to do from an installation application... but
it serves as a workaround on other Unix systems to prevent servers from
having to be SUID, which seems like a greater risk than the "crash and
start a new untrusted server" scenario...
sean
Glenn Anderson wrote:
All true, but this debate was waged and lost two years ago.
Someone must have forgotten to invite me to that debate. I have yet to
hear any sort of convincing argument as to why removing the
restriction on ports less than 1024 would be a bad thing. Is there
anyone on this list who thinks removing the restriction would be a bad
thing?
There are reasonable solutions for BSD Sockets using a SUID root
helper app.
I have not seen any reasonable solutions, they all seem to involve
authorization then setting some helper application to run as root,
which opens a whole different can of worms as far as security goes.
Apple needs to publish better sample code, but there are some
examples available.
Apple needs to come up with a good solution to this problem, and no
amount of sample code is going to solve it.
Glenn.
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.