Not to continue offtopic for too much longer, but IMHO, the "only root can bind to ports under 1025" was, and continues to be, a terrible UNIX hack that was possibly reasonable at its time of inception, but that has since *caused* more security holes than it ever helped to prevent. The argument for the hack is backwards compatibility, any other explanation usually ends up as rationalization or circular logic. My $.02.
-----Original Message----- From: Bill Anderson [mailto:bill@libc.org] Sent: Sunday, July 30, 2000 5:04 PM To: zope@zope.org Subject: Re: [Zope] Starting Zope
(Quoting reversed for sake of continuity.
On Sun, 30 Jul 2000, Cary O'Brien wrote:
Cary O'Brien wrote:
Well...
If you are running on Linux you could simply edit the kernel code to elimitate the check on being root to bind to low ports. That's what we did.
Which is an even worse idea.
Why? On a sufficiently firewalled off box, where the few logins are completly trusted, what's the diff? If you were worried about people cracking a user account and getting underneath telnet, than limit the lifting of the restriction to port 80. If you are concerned that non-root users could launch attacks from low ports at other machines, assuming that only good guys can come from low ports is pretty naive.
The whole business about not letting anyone but root bind to low ports makes sense for a public access machine where all the first year engineering students have an account, but for a dedicated application server it is kind of misdirected. You ought to be running next to nothing but the application, and you had better trust everyone that you give a login to, and you out to have the thing locked down/firewalled well. So the tiny bit of possible protection may not be worth the hassle/risks of writing your own suid-wrapper, or the complexity of having a redirect and messing with site-access so that the port numbers in the zope -- what it is that parameter -- base or whatever, comes out write.
Just for fun - does NT have the same restriction?
Nitesh Dhanjani wrote:
Interesting argument. However, consider this: if you
completely trust your
'firewalled' box, then why not run the web server as root? One response, in your case is the fact that you mention your trust on users(humans are the most easy to compromise, however that argument is a bit OT). However, do you trust all of your webserver code? Do you trust your cgi-bin scripts and applications? And by trust I not only mean harmful intent by the authors of software, but unintentional bugs which can be exploited, and will be given the privilege to bind to <1024 ports even when they run as a user with least privileges.
Exactly. In addition, relying solely on a firewall is a bad idea from a security standpoint. Firewalls can. and do get breached.
I don't run many services on _any_ of my machines for security reasons. I certainly don't want Joe Random User to fire them up either. Consider tftpd, or telnetd, or rlogin, rusers, rwho, ruptime, etc.. There are many ways a user can compromise, not only the machine he is on, but other machines by having the capability to bind to ports under 1024.
Nearly all of them are off topic for this list; thus I would recommend a number of the security resources available on the web, such as:
http://www.rootshell.com http://www.securityfocus.com
Just a quick example: A user can upload a custom compiled version of (insert servie such as DNS, NIS, telnetd, httpd, etc> that uses his/her local libraries, bypass /etc/services. since they can bind to ports under 1025, they can be started by the user. Whereas, for example, on other systems, their app would fail. Now, consider that if they used a version of, say ftpd, or fingerd, or named, that has known security openings, they can then exploit this to get root accounts; the firewall being bypassed by being local to the machine.
Remember, Cary, if you don't think like a cracker/hacker, you can't stop them. If you can't see why allowing users (and users' programs) can be a problem, doing so is an violaiton of the basic premise of good security: That which is not specifically allowed, is denied.
And, BTW, for the record, I handle Unix/Network security for a company known as Hewlett-Packard, so I think I have a good idea of the risks and potnetial exploits ;)
-- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )