Edit - Super User

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

Rev

Required fields*

Allow non-root process to bind to port 80 and 443?

Is it possible to tune a kernel parameter to allow a userland program to bind to port 80 and 443?

The reason I ask is I think its foolish to allow a privileged process to open a socket and listen. Anything that opens a socket and listens is high risk, and high risk applications should not be running as root.

I'd much rather try to figure out what unprivileged process is listening on port 80 rather than trying to remove malware that burrowed in with root privileges.

Answer*

Dale Hagglund is spot on.  So I'm just going to say the same thing but in a different way, with some specifics and examples.  &#9786;

The right thing to do in the Unix and Linux worlds is:

- to have a small, simple, easily auditable, program that runs as the superuser and binds the listening socket;
- to have another small, simple, easily auditable, program that drops privileges, spawned by the first program;
- to have the meat of the service, in a separate _third_ program, run under a non-superuser account and chain loaded by the second program, expecting to simply inherit an open file descriptor for the socket.

You have the wrong idea of where the high risk is.  The high risk is in _reading from the network and acting upon what is read_ not in the simple acts of opening a socket, binding it to a port, and calling `listen()`.  It's the part of a service that does the actual communication that is the high risk.  The parts that open, `bind()`, and `listen()`, and even (to an extent) the part that `accepts()`, are not the high risk and can be run under the aegis of the superuser.  They don't use and act upon (with the exception of source IP addresses in the `accept()` case) data that are under the control of untrusted strangers over the network.

There are many ways of doing this.

## `inetd`

As Dale Hagglund says, the old "network superserver" `inetd` does this.  The account under which the service process is run is one of the columns in `inetd.conf`.  It doesn't separate the listening part and the dropping privileges part into two separate programs, small and easily auditable, but it does separate off the main service code into a separate program, `exec()`ed in a service process that it spawns with an open file descriptor for the socket.

The difficulty of auditing isn't that much of a problem, as one only has to audit the one program.  `inetd`'s major problem is not auditing so much but is rather that it doesn't provide simple fine-grained runtime service control, compared to more recent tools.

## UCSPI-TCP and daemontools

Daniel J. Bernstein's [UCSPI-TCP](http://cr.yp.to/ucspi-tcp.html) and [daemontools](http://cr.yp.to/daemontools.html) packages were designed to do this in conjunction.  One can alternatively use Bruce Guenter's largely equivalent [daemontools-encore](http://untroubled.org/daemontools-encore/) toolset.

The program to open the socket file descriptor and bind to the privileged local port is [`tcpserver`](http://cr.yp.to/ucspi-tcp/tcpserver.html), from UCSPI-TCP.  It does both the `listen()` and the `accept()`.

`tcpserver` then spawns either a service program that drops root privileges itself (because the protocol being served involves starting out as the superuser and then "logging on", as is the case with, for example, an FTP or an SSH daemon) or [`setuidgid`](http://cr.yp.to/daemontools/setuidgid.html) which is a self-contained small and easily auditable program that solely drops privileges and then chain loads to the service program proper (no part of which thus ever runs with superuser privileges, as is the case with, say, [`qmail-smtpd`](http://www.qmail.org/qmail-manual-html/man8/qmail-smtpd.html)).

A service `run` script would thus be for example (this one for [dummyidentd](https://deekayen.net/sites/dkn.me/files/files/dummyidentd.html) for providing null IDENT service):

    #!/bin/sh -e
    exec 2>&1
    exec \
    tcpserver 0 113 \
    setuidgid nobody \
    dummyidentd.pl

## nosh

[My nosh package](http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html) is designed to do this.  It has a small `setuidgid` utility, just like the others.  One slight difference is that it's usable with `systemd`-style "LISTEN_FDS" services as well as with UCSPI-TCP services, so the traditional `tcpserver` program is replaced by two separate programs: `tcp-socket-listen` and `tcp-socket-accept`.

Again, single-purpose utilities spawn and chain load one another.  One interesting quirk of the design is that one can drop superuser privileges after `listen()` but before even `accept()`.  Here's a `run` script for `qmail-smtpd` that indeed does exactly that:

    #!/bin/nosh
    fdmove -c 2 1
    clearenv --keep-path --keep-locale
    envdir env/
    softlimit -m 70000000
    tcp-socket-listen --combine4and6 --backlog 2 ::0 smtp
    setuidgid qmaild
    sh -c 'exec \
    tcp-socket-accept -v -l "${LOCAL:-0}" -c "${MAXSMTPD:-1}" \
    ucspi-socket-rules-check \
    qmail-smtpd \
    '

The programs that run under the aegis of the superuser are the small service-agnostic chain-loading tools `fdmove`, `clearenv`, `envdir`, ` softlimit`, `tcp-socket-listen`, and `setuidgid`.  By the point that `sh` is started, the socket is open and bound to the `smtp` port, and the process no longer has superuser privileges.

## s6, s6-networking, and execline

Laurent Bercot's [s6](http://skarnet.org/software/s6/) and [s6-networking](http://skarnet.org/software/s6-networking/) packages were designed to do this in conjunction.  The commands are structurally very similar to those of `daemontools` and UCSPI-TCP.  

`run` scripts would be much the same, except for the substitution of [`s6-tcpserver`](http://skarnet.org/software/s6-networking/s6-tcpserver.html) for `tcpserver` and [`s6-setuidgid`](http://skarnet.org/software/s6/s6-setuidgid.html) for `setuidgid`.  However, one might also choose to make use of M. Bercot's [execline](http://skarnet.org/software/execline/) toolset at the same time.

Here's an example of an FTP service, lightly modified from [Wayne Marshall's original](http://thedjbway.b0llix.net/publicfile/ftpd.html), that uses execline, s6, s6-networking, and the FTP server program from [publicfile](http://cr.yp.to/publicfile.html):

    #!/command/execlineb -PW
    multisubstitute {
        define CONLIMIT 41
        define FTP_ARCHIVE "/var/public/ftp"
    }
    fdmove -c 2 1
    s6-envuidgid pubftp 
    s6-softlimit -o25 -d250000 
    s6-tcpserver -vDRH -l0 -b50 -c ${CONLIMIT} -B '220 Features: a p .' 0 21 
    ftpd ${FTP_ARCHIVE}

## ipsvd

Gerrit Pape's [ipsvd](http://smarden.org/ipsvd/index.html) is another toolset that runs along the same lines as ucspi-tcp and s6-networking.  The tools are `chpst` and `tcpsvd` this time, but they do the same thing, and the high risk code that does the reading, processing, and writing of things sent over the network by untrusted clients is still in a separate program.

Here's [M. Pape's example](http://smarden.org/ipsvd/examples.html) of running [`fnord`](http://www.fefe.de/fnord/) in a `run` script:

    #!/bin/sh
    exec 2>&1
    cd /public/10.0.5.4
    exec \
    chpst -m300000 -Uwwwuser \
    tcpsvd -v 10.0.5.4 443 sslio -v -unobody -//etc/fnord/jail -C./cert.pem \
    fnord

## `systemd`

[`systemd`](http://freedesktop.org/wiki/Software/systemd/), the new service supervision and init system that can be found in some Linux distributions, [is intended to do what `inetd` can do](http://0pointer.de/blog/projects/inetd.html).  However, it doesn't use a suite of small self-contained programs.  One has to audit `systemd` in its entirety, unfortunately.

With `systemd` one creates configuration files to define a socket that `systemd` listens on, and a service that `systemd` starts.  The service "unit" file has settings that allow one a great deal of control over the service process, including what user it runs as.

With that user set to be a non-superuser, `systemd` does all of the work of opening the socket, binding it to a port, and calling `listen()` (and, if required, `accept()`) in process #1 as the superuser, and the service process that it spawns runs without superuser privileges.

Edit Summary*

Cancel

3

Thanks for the compliment. This is a great collection of concrete advice. +1.

Dale Hagglund
– Dale Hagglund

2014-04-23 23:13:18 +00:00
Commented Apr 23, 2014 at 23:13
2

so much reading... I just want to serve static files

user383438
– user383438

2021-09-26 10:45:04 +00:00
Commented Sep 26, 2021 at 10:45
Maybe you could add the phrase socket activation? I think that is the common terminology for referring to this systemd feature.

Erik Sjölund
– Erik Sjölund

2023-11-21 13:58:50 +00:00
Commented Nov 21, 2023 at 13:58

Add a comment |

Correct minor typos or mistakes
Clarify meaning without changing it
Add related resources or links
Always respect the author’s intent
Don’t use edits to reply to the author

create code fences with backticks ` or tildes ~
```
like so
```
add language identifier to highlight code
```python
def function(foo):
print(foo)
```
put returns between paragraphs
for linebreak add 2 spaces at end
_italic_ or **bold**
indent code by 4 spaces
backtick escapes `like _so_`
quote by placing > at start of line
to make links (use https whenever possible)

<https://example.com>

[example](https://example.com)

<a href="https://example.com">example</a>

formatting help »
answering help »