From: John Lange <john.lange@bighostbox.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: A new model for ports and kernel security?
Date: Wed, 01 Oct 2003 14:06:23 -0500 [thread overview]
Message-ID: <1065035183.5142.50.camel@mars> (raw)
It will not surprise me if this topic has been discussed before but my
search of the archives did not turn up anything meaningful.
I have a question and a suggestion.
What I'm wondering is, why do we have this requirement that only root
processes can connect to low ports (under 1024) ?
My understanding is that this is a hold-over from ancient days gone past
where it was meant to be a security feature. Since only root processes
can listen on ports less than 1024, you could "trust" any connection
made to a low port to be "secure". In other words, nobody could be
"bluffing" on a telnet port that didn't have root access therefore it
was "safe" to type in your password.
I don't know if the above is the real reason or not but if it is,
clearly it has outlived its usefulness as a "security" feature.
Regardless, does not the requirement that only root can bind to low
ports now create more of a security problem than it ever solved?
Are not processes forced to run as root (at least at startup) that have
security holes in them not the leading cause of "remote root exploits"?
So if the root-low-port requirement isn't serving any purpose and is
indeed the cause of security problems is it not time to do away with it?
Furthermore, while only root can bind to low-ports, ANY user can bind to
high ports. This also causes a ton of security concerns as well!
So I would like to propose the following improvement to kernel security
and I invite your comments.
Suggestion: A groups based port binding security system for both
outgoing and incoming port binding.
For example, the group "root" is allowed to listen to ports "*" (all)
and allowed outgoing connections to "*" (all) as well.
The group "www" would be allowed to bind to ports "80, 443" (http,
https) and not allowed ANY outgoing connections.
The group "mail" (or postfix, or whatever) would be allowed to listen to
port "25" (smtp) and connect to "25".
The group "users" would not be allowed to listen at all but might be
allowed to connect to 20-21, 80, 443.
etc.
This accomplishes two major things:
- no process ever needs to run as root.
- no unauthorized process can ever listen on a port or make connections.
On servers that allow remote users this prevents things like bots, spam
relays, ftp drops and all sorts of mischief.
I envision a simplistic "/etc/ports" with the format,
"<groupid>,<incoming ports>,<outgoing ports>"
I realize similar things can be accomplished in other ways (with
iptables I believe) but it just seems to me that this should be a
fundamental part of the systems security and therefore should be in the
kernel by default (just as the root binding to low ports is currently).
I hereby make the disclaimer that I am not a kernel hacker, just a
sysadmin. So feel free to give me the smackdown if this violates some
kernel rule.
--
John Lange
next reply other threads:[~2003-10-01 19:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-01 19:06 John Lange [this message]
2003-10-01 19:27 ` A new model for ports and kernel security? James Morris
2003-10-02 1:45 ` John Lange
2003-10-02 13:22 ` Jesse Pollard
2003-10-02 14:30 ` John Lange
2003-10-06 8:06 ` Hans Reiser
2003-10-01 19:28 ` Valdis.Kletnieks
2003-10-01 20:10 ` Krzysztof Halasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1065035183.5142.50.camel@mars \
--to=john.lange@bighostbox.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox