Re: Liberating locked up ports
Re: Liberating locked up ports
- Subject: Re: Liberating locked up ports
- From: Glenn Anderson <email@hidden>
- Date: Thu, 30 Jan 2003 10:09:59 +1300
At 12:40am -0600 29/1/2003, Sean Bullington wrote:
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.)
I can see your point, but that does require multiple security
failures (allowing users access to a server, and running a buggy web
server) to take advantage of it, and still only effects one service
on the server. On the other hand, a root exploit in something like
bind is a single failure with much more severe consequences. So while
removing the less than 1024 port restriction is not the best
solution, it would still improve security.
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.
As someone who writes server software, I would like to see this
change in servers as well, I would much prefer people were not
running my software as root.
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.
The settings could easily default to only allowing root to bind to
ports less than 1024. Or better yet, just default to that on OS X
Server and default to allowing any user on OS X Client.
However, you can only babysit admins to a certain point...
As someone who writes easy to use server software, that sort of admin
is probably a significant part of my customer base. I would prefer it
if there simply were not security issues for them to be ignorant
about, like on OS 9.
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 :)
It achieves the same results as removing the root restriction, but
complicates configuration, my server currently listens on 9
privileged ports, it would need all of them changed, and a port
redirection would have to be added for each one. On OS 9, or even
under Classic, someone can just launch my server, enter an admin
password, and they are ready to go.
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...
I believe one of my users has done something like this under OS X.
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.