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/