Messages in this thread | | | Subject | Re: setting access rights to priviledged ports | Date | Tue, 20 Oct 1998 13:07:24 +0200 | From | Olaf Titz <> |
| |
> >(Btw. for any services started from inetd there is a trivial way to > >shut them down.) > Is this trivial way doable by a normal user? If so then this is a serious
It is even doable from remote. Connect more than 40 times in 60 seconds to that port, and inetd will shut it down in the mistaken assumption that the server is failing. At least that is the standard configuration (you can override that in inetd.conf with newer versions). Big problem for people who run SMTP from inetd, because a sudden upsurge in innocent incoming mail can trigger it.
> security bug. If this trick is only doable by root then the mail is already > as good as stolen. And if a normal user is able to shutdown inetd deamons > then wouldn't he still have to free the port from its usage by inetd?
inetd does shut down the socket it listens on for that service. The next connect gets "connection refused". And AFAIK inetd won't resume servicing that port until it gets a HUP.
This doesn't enable non-root to steal ports, _if_ the ports in question are below 1024. Just an easy DOS attack.
> Could proper permissions on /proc solve this?
No. The only solution is to not run any services on ports >1024 from inetd, or compile a version of inetd which doesn't have this feature. And don't run security-relevant services on ports >1024 at all - that's what the "only root can bind" requirement is for in the first place. If you don't want to run your smtpd as root, use an MTA which doesn't need root (qmail, vmailer) and run it from inetd under its own UID, but on port 25. That's how it works now; certainly it would be desirable to have an ACL solution for ports.
Most problems with the privileged ports binding result from bad usage in user space: mis-designed protocols (the r* stuff) or daemons which don't drop their privileges (sendmail); INN shows a better solution.
olaf
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |