A new model for ports and kernel security?

From: John Lange (john.lange_at_bighostbox.com)
Date: 10/01/03

  • Next message: Christian Kujau: "Re: Dependency bug? Alsa es1370 needs joystick support" 
    Date:	Wed, 01 Oct 2003 14:06:23 -0500
To: Linux Kernel <linux-kernel@vger.kernel.org>

    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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Christian Kujau: "Re: Dependency bug? Alsa es1370 needs joystick support"

    Relevant Pages

    • Re: Hardening a Solaris system.
      ... > I know files that execute with root permissions by normal users (e.g. ... > I've set up a web server, running Apache, so are thinking about what I ... thing to leave enabled in here might be a backup port. ... there are security steps here. ...
      (comp.security.unix)
    • Re: Hardening a Solaris system.
      ... > I know files that execute with root permissions by normal users (e.g. ... > I've set up a web server, running Apache, so are thinking about what I ... thing to leave enabled in here might be a backup port. ... there are security steps here. ...
      (comp.unix.solaris)
    • 5.2.1 -> 5.3 ==> vinum start -> panic: unmount: dangling vnode
      ... booted into single user mode & installed new kernel ... Mounting root from ufs:/dev/ad0s2a ... pci0: <PCI bus> on pcib0 ... <Parallel port bus> on ppc0 ...
      (freebsd-current)
    • Re: [Reviews requested] kern/121073: chroot for non-root users
      ... I've attached the patch to this email as well. ... This call allows the processes to share filedesc table, that, among other information, contains the root of the filesystem namespace for the process. ... There is a long and sordid history of vulnerability associated with the use of the chrootsystem call in well-meaning attempts to allow users to employ it in order to improve security. ... Most of the lessons center on the high level of trust placed in the file system name space by UNIX applications *and* the kernel, and the unexpected implications of allowing that namespace to be manipulated by untrusted processes. ...
      (freebsd-arch)
    • Re: chmod wont work unless Im the owner, or root
      ... >[This is a security restriction. ... We wouldn't want arbitrary users changing ... ordinary user root power is dangerous. ... do whatever the kernel thinks is best. ...
      (alt.os.linux)