Is there a way for non-root processes to bind to privileged ports on Linux

Question

It s very annoying to have this limitation on my development box  when there won t ever be any users other than me   I m aware of the standard workarounds  but none of them do exactly what I want    authbind  The version in Debian testing  1 0  only supports IPv4  Using the iptables REDIRECT target to redirect a low port to a high port  the  nat  table is not yet implemented for ip6tables  the IPv6 version of iptables  sudo  Running as root is what I m trying to avoid  SELinux  or similar    This is just my dev box  I don t want to introduce a lot of extra complexity     Is there some simple sysctl variable to allow non-root processes to bind to  privileged  ports  ports less than 1024  on Linux  or am I just out of luck   EDIT  In some cases  you can use capabilities to do this

User · Answer

Modern Linux supports  sbin sysctl -w net ipv4 ip unprivileged port start 0

User · Answer

You can do a port redirect   This is what I do for a Silverlight policy server running on a Linux box  iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 943 -j REDIRECT --to-port 1300

User · Answer

Two other simple possibilities   There is an old  unfashionable  solution to the  a daemon that binds on a low port and hands control to your daemon   It s called inetd  or xinetd   The cons are    your daemon needs to talk on stdin stdout  if you don t control the daemon -- if you don t have the source -- then this is perhaps a showstopper  although some services may have an inetd-compatibility flag  a new daemon process is forked for every connection it s one extra link in the chain   Pros    available on any old UNIX once your sysadmin has set up the config  you re good to go about your development  when you re-build your daemon  might you lose setcap capabilities  And then you ll have to go back to your admin  please sir      daemon doesn t have to worry about that networking stuff  just has to talk on stdin stdout can configure to execute your daemon as a non-root user  as requested   Another alternative  a hacked-up proxy  netcat or even something more robust  from the privileged port to some arbitrary high-numbered port where you can run your target daemon   Netcat is obviously not a production solution  but  just my dev box   right    This way you could continue to use a network-capable version of your server  would only need root sudo to start proxy  at boot   wouldn t be relying on complex potentially fragile capabilities

User · Answer

At startup   iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080   Then  you can bind to the port you forward to

User · Answer

Okay  thanks to the people who pointed out the capabilities system and CAP NET BIND SERVICE capability  If you have a recent kernel  it is indeed possible to use this to start a service as non-root but bind low ports  The short answer is that you do   setcap  cap net bind service  ep   path to program   And then anytime program is executed thereafter it will have the CAP NET BIND SERVICE capability  setcap is in the debian package libcap2-bin   Now for the caveats    You will need at least a 2 6 24 kernel This won t work if your file is a script   ie  uses a    line to launch an interpreter   In this case  as far I as understand  you d have to apply the capability to the interpreter executable itself  which of course is a security nightmare  since any program using that interpreter will have the capability  I wasn t able to find any clean  easy way to work around this problem  Linux will disable LD LIBRARY PATH on any program that has elevated privileges like setcap or suid   So if your program uses its own     lib   you might have to look into another option like port forwarding    Resources    capabilities 7  man page  Read this long and hard if you re going to use capabilities in a production environment  There are some really tricky details of how capabilities are inherited across exec   calls that are detailed here  setcap man page  Bind ports below 1024 without root on GNU Linux   The document that first pointed me towards setcap    Note  RHEL first added this in v6

User · Answer

The standard way is to make them  setuid  so that they start up as root  and then they throw away that root privilege as soon as they ve bound to the port but before they start accepting connections to it   You can see good examples of that in the source code for Apache and INN   I m told that Lighttpd is another good example   Another example is Postfix  which uses multiple daemons that communicate through pipes  and only one or two of them  which do very little except accept or emit bytes  run as root and the rest run at a lower privilege

User · Answer

My  standard workaround  uses socat as the user-space redirector   socat tcp6-listen 80 fork tcp6 8080   Beware that this won t scale  forking is expensive but it s the way socat works

User · Answer

You can setup a local SSH tunnel  eg if you want port 80 to hit your app bound to 3000   sudo ssh  USERNAME localhost -L 80 localhost 3000 -N   This has the advantage of working with script servers  and being very simple

User · Answer

Use the privbind utility  it allows  an  unprivileged  application to bind to reserved ports

User · Answer

Linux supports capabilities to support more fine-grained permissions than just  this application is run as root   One of those capabilities is CAP NET BIND SERVICE which is about binding to a privileged port   lt 1024    Unfortunately I don t know how to exploit that to run an application as non-root while still giving it CAP NET BIND SERVICE  probably using setcap  but there s bound to be an existing solution for this

User · Answer

Okay  thanks to the people who pointed out the capabilities system and CAP NET BIND SERVICE capability  If you have a recent kernel  it is indeed possible to use this to start a service as non-root but bind low ports  The short answer is that you do   setcap  cap net bind service  ep   path to program   And then anytime program is executed thereafter it will have the CAP NET BIND SERVICE capability  setcap is in the debian package libcap2-bin   Now for the caveats    You will need at least a 2 6 24 kernel This won t work if your file is a script   ie  uses a    line to launch an interpreter   In this case  as far I as understand  you d have to apply the capability to the interpreter executable itself  which of course is a security nightmare  since any program using that interpreter will have the capability  I wasn t able to find any clean  easy way to work around this problem  Linux will disable LD LIBRARY PATH on any program that has elevated privileges like setcap or suid   So if your program uses its own     lib   you might have to look into another option like port forwarding    Resources    capabilities 7  man page  Read this long and hard if you re going to use capabilities in a production environment  There are some really tricky details of how capabilities are inherited across exec   calls that are detailed here  setcap man page  Bind ports below 1024 without root on GNU Linux   The document that first pointed me towards setcap    Note  RHEL first added this in v6

User · Answer

The standard way is to make them  setuid  so that they start up as root  and then they throw away that root privilege as soon as they ve bound to the port but before they start accepting connections to it   You can see good examples of that in the source code for Apache and INN   I m told that Lighttpd is another good example   Another example is Postfix  which uses multiple daemons that communicate through pipes  and only one or two of them  which do very little except accept or emit bytes  run as root and the rest run at a lower privilege

User · Answer

Answer at 2015 Sep   ip6tables now supports IPV6 NAT  http   www netfilter org projects iptables files changes-iptables-1 4 17 txt  You will need kernel 3 7   Proof    09 09 23  root X   ip6tables -t nat -vnL Chain PREROUTING  policy ACCEPT 0 packets  0 bytes   pkts bytes target     prot opt in     out     source               destination     0     0 REDIRECT   tcp      eth0              0                    0                 tcp dpt 80 redir ports 8080     0     0 REDIRECT   tcp      eth0              0                    0                 tcp dpt 443 redir ports 1443  Chain INPUT  policy ACCEPT 0 packets  0 bytes   pkts bytes target     prot opt in     out     source               destination  Chain OUTPUT  policy ACCEPT 6148 packets  534K bytes   pkts bytes target     prot opt in     out     source               destination  Chain POSTROUTING  policy ACCEPT 6148 packets  534K bytes   pkts bytes target     prot opt in     out     source               destination

User · Answer

Since the OP is just development testing  less than sleek solutions may be helpful   setcap can be used on a script s interpreter to grant capabilities to scripts   If setcaps on the global interpreter binary is not acceptable  make a local copy of the binary  any user can  and get root to setcap on this copy   Python2  at least  works properly with a local copy of the interpreter in your script development tree   No suid is needed so the root user can control to what capabilities users have access   If you need to track system-wide updates to the interpreter  use a shell script like the following to run your script      bin sh      Watch for updates to the Python2 interpreter  PRG python net raw PRG ORIG  usr bin python2 7  cmp  PRG ORIG  PRG          echo        echo         PRG ORIG has been updated            echo  Run the following commands to refresh  PRG       echo        echo        cp  PRG ORIG  PRG      echo        setcap cap net raw ep  PRG      echo        exit       PRG

User · Answer

Since the OP is just development testing  less than sleek solutions may be helpful   setcap can be used on a script s interpreter to grant capabilities to scripts   If setcaps on the global interpreter binary is not acceptable  make a local copy of the binary  any user can  and get root to setcap on this copy   Python2  at least  works properly with a local copy of the interpreter in your script development tree   No suid is needed so the root user can control to what capabilities users have access   If you need to track system-wide updates to the interpreter  use a shell script like the following to run your script      bin sh      Watch for updates to the Python2 interpreter  PRG python net raw PRG ORIG  usr bin python2 7  cmp  PRG ORIG  PRG          echo        echo         PRG ORIG has been updated            echo  Run the following commands to refresh  PRG       echo        echo        cp  PRG ORIG  PRG      echo        setcap cap net raw ep  PRG      echo        exit       PRG

User · Answer

Port redirect made the most sense for us  but we ran into an issue where our application would resolve a url locally that also needed to be re-routed   that means you shindig     This will also allow you to be redirected when accessing the url on the local machine   iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080 iptables -A OUTPUT -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080

User · Answer

Port redirect made the most sense for us  but we ran into an issue where our application would resolve a url locally that also needed to be re-routed   that means you shindig     This will also allow you to be redirected when accessing the url on the local machine   iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080 iptables -A OUTPUT -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080

User · Answer

File capabilities are not ideal  because they can break after a package update   The ideal solution  IMHO  should be an ability to create a shell with inheritable CAP NET BIND SERVICE set   Here s a somewhat convoluted way to do this   sg  DAEMONUSER  capsh --keep 1 --uid  id -u  DAEMONUSER         --caps  cap net bind service pei  --        YOUR COMMAND GOES HERE    capsh utility can be found in libcap2-bin package in Debian Ubuntu distributions  Here s what goes on    sg changes effective group ID to that of the daemon user  This is necessary because capsh leaves GID unchanged and we definitely do not want it  Sets bit  keep capabilities on UID change   Changes UID to  DAEMONUSER Drops all caps  at this moment all caps are still present because of --keep 1   except inheritable cap net bind service Executes your command   --  is a separator    The result is a process with specified user and group  and cap net bind service privileges   As an example  a line from ejabberd startup script   sg  EJABBERDUSER  capsh --keep 1 --uid  id -u  EJABBERDUSER  --caps  cap net bind service pei  --  EJABBERD --noshell -detached

User · Answer

Two other simple possibilities   There is an old  unfashionable  solution to the  a daemon that binds on a low port and hands control to your daemon   It s called inetd  or xinetd   The cons are    your daemon needs to talk on stdin stdout  if you don t control the daemon -- if you don t have the source -- then this is perhaps a showstopper  although some services may have an inetd-compatibility flag  a new daemon process is forked for every connection it s one extra link in the chain   Pros    available on any old UNIX once your sysadmin has set up the config  you re good to go about your development  when you re-build your daemon  might you lose setcap capabilities  And then you ll have to go back to your admin  please sir      daemon doesn t have to worry about that networking stuff  just has to talk on stdin stdout can configure to execute your daemon as a non-root user  as requested   Another alternative  a hacked-up proxy  netcat or even something more robust  from the privileged port to some arbitrary high-numbered port where you can run your target daemon   Netcat is obviously not a production solution  but  just my dev box   right    This way you could continue to use a network-capable version of your server  would only need root sudo to start proxy  at boot   wouldn t be relying on complex potentially fragile capabilities

User · Answer

You can do a port redirect   This is what I do for a Silverlight policy server running on a Linux box  iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 943 -j REDIRECT --to-port 1300

User · Answer

There is also the  djb way    You can use this method to start your process as root running on any port under tcpserver  then it will hand control of the process to the user you specify immediately after the process starts        bin sh  UID   id -u username  GID   id -g username  exec tcpserver -u    UID   -g    GID   -RHl0 0 port  path to binary  amp    For more info  see  http   thedjbway b0llix net daemontools uidgid html

User · Answer

Bind port 8080 to 80 and open port 80  sudo iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080 sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT  and then run program on port 8080 as a normal user  you will then be able to access http   127 0 0 1 on port 80

User · Answer

Okay  thanks to the people who pointed out the capabilities system and CAP NET BIND SERVICE capability  If you have a recent kernel  it is indeed possible to use this to start a service as non-root but bind low ports  The short answer is that you do   setcap  cap net bind service  ep   path to program   And then anytime program is executed thereafter it will have the CAP NET BIND SERVICE capability  setcap is in the debian package libcap2-bin   Now for the caveats    You will need at least a 2 6 24 kernel This won t work if your file is a script   ie  uses a    line to launch an interpreter   In this case  as far I as understand  you d have to apply the capability to the interpreter executable itself  which of course is a security nightmare  since any program using that interpreter will have the capability  I wasn t able to find any clean  easy way to work around this problem  Linux will disable LD LIBRARY PATH on any program that has elevated privileges like setcap or suid   So if your program uses its own     lib   you might have to look into another option like port forwarding    Resources    capabilities 7  man page  Read this long and hard if you re going to use capabilities in a production environment  There are some really tricky details of how capabilities are inherited across exec   calls that are detailed here  setcap man page  Bind ports below 1024 without root on GNU Linux   The document that first pointed me towards setcap    Note  RHEL first added this in v6

User · Answer

The standard way is to make them  setuid  so that they start up as root  and then they throw away that root privilege as soon as they ve bound to the port but before they start accepting connections to it   You can see good examples of that in the source code for Apache and INN   I m told that Lighttpd is another good example   Another example is Postfix  which uses multiple daemons that communicate through pipes  and only one or two of them  which do very little except accept or emit bytes  run as root and the rest run at a lower privilege

User · Answer

Or patch your kernel and remove the check    Option of last resort  not recommended    In net ipv4 af inet c  remove the two lines that read        if  snum  amp  amp  snum  lt  PROT SOCK  amp  amp   capable CAP NET BIND SERVICE                 goto out    and the kernel won t check privileged ports anymore

User · Answer

With systemd  you just need to slightly modify your service to accept preactivated sockets   You can later use systemd socket activate   No capabilities  iptables or other tricks are needed   This is content of relevant systemd files from this example of simple python http server  File httpd-true service   Unit  Description Httpd true    Service  ExecStart  usr local bin httpd-true User subsonic  PrivateTmp yes   File httpd-true socket   Unit  Description HTTPD true   Socket  ListenStream 80   Install  WantedBy default target

User · Answer

Bind port 8080 to 80 and open port 80  sudo iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080 sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT  and then run program on port 8080 as a normal user  you will then be able to access http   127 0 0 1 on port 80

User · Answer

Use the privbind utility  it allows  an  unprivileged  application to bind to reserved ports

User · Answer

There is also the  djb way    You can use this method to start your process as root running on any port under tcpserver  then it will hand control of the process to the user you specify immediately after the process starts        bin sh  UID   id -u username  GID   id -g username  exec tcpserver -u    UID   -g    GID   -RHl0 0 port  path to binary  amp    For more info  see  http   thedjbway b0llix net daemontools uidgid html

User · Answer

TLDR  For  the answer   as I see it   jump down to the   TLDR lt  lt  part in this answer   OK  I ve figured it out  for real this time   the answer to this question  and this answer of mine is also a way of apologizing for promoting another answer  both here and on twitter  that I thought was  the best   but after trying it  discovered that I was mistaken about that  Learn from my mistake kids  don t promote something until you ve actually tried it yourself   Again  I reviewed all the answers here  I ve tried some of them  and chose not to try others because I simply didn t like the solutions   I thought that the solution was to use systemd with its Capabilities  and CapabilitiesBindingSet  settings  After wrestling with this for some time  I discovered that this is not the solution because   Capabilities are intended to restrict root processes   As the OP wisely stated  it is always best to avoid that  for all your daemons if possible     You cannot use the Capabilities related options with User  and Group  in systemd unit files  because capabilities are ALWAYS reset when execev  or whatever the function is  is called  In other words  when systemd forks and drops its perms  the capabilities are reset  There is no way around this  and all that binding logic in the kernel is basic around uid 0  not capabilities  This means that it is unlikely that Capabilities will ever be the right answer to this question  at least any time soon   Incidentally  setcap  as others have mentioned  is not a solution  It didn t work for me  it doesn t work nicely with scripts  and those are reset anyways whenever the file changes   In my meager defense  I did state  in the comment I ve now deleted   that James  iptables suggestion  which the OP also mentions   was the  2nd best solution    -P    TLDR lt  lt   The solution is to combine systemd with on-the-fly iptables commands  like this  taken from DNSChain     Unit  Description dnschain After network target Wants namecoin service   Service  ExecStart  usr local bin dnschain Environment DNSCHAIN SYSD VER 0 0 1 PermissionsStartOnly true ExecStartPre  sbin sysctl -w net ipv4 ip forward 1 ExecStartPre - sbin iptables -D INPUT -p udp --dport 5333 -j ACCEPT ExecStartPre - sbin iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333 ExecStartPre  sbin iptables -A INPUT -p udp --dport 5333 -j ACCEPT ExecStartPre  sbin iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333 ExecStopPost  sbin iptables -D INPUT -p udp --dport 5333 -j ACCEPT ExecStopPost  sbin iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333 User dns Group dns Restart always RestartSec 5 WorkingDirectory  home dns PrivateTmp true NoNewPrivileges true ReadOnlyDirectories  etc    Unfortunately  capabilities are basically worthless because they re designed to restrict root daemons  Instead  we use iptables to listen on privileged ports    Capabilities cap net bind service pei   SecureBits keep-caps   Install  WantedBy multi-user target   Here we accomplish the following    The daemon listens on 5333  but connections are successfully accepted on 53 thanks to iptables We can include the commands in the unit file itself  and thus we save people headaches  systemd cleans up the firewall rules for us  making sure to remove them when the daemon isn t running  We never run as root  and we make privilege escalation impossible  at least systemd claims to   supposedly even if the daemon is compromised and sets uid 0    iptables is still  unfortunately  quite an ugly and difficult-to-use utility  If the daemon is listening on eth0 0 instead of eth0  for example  the commands are slightly different

User · Answer

I know this is an old question  but now with recent     4 3  kernels there is finally a good answer to this - ambient capabilities   The quick answer is to grab a copy of the latest  as-yet-unreleased  version of libcap from git and compile it  Copy the resulting progs capsh binary somewhere   usr local bin is a good choice   Then  as root  start your program with   usr local bin capsh --keep 1 --user  your-service-user-name        --inh  cap net bind service  --addamb  cap net bind service         -- -c  your-program    In order  we are   Declaring that when we switch users  we want to keep our current capability sets Switching user  amp  group to  your-service-user-name  Adding the cap net bind service capability to the inherited  amp  ambient sets Forking bash -c  your-command   since capsh automatically starts bash with the arguments after --    There s a lot going on under the hood here   Firstly  we are running as root  so by default  we get a full set of capabilities  Included in this is the ability to switch uid  amp  gid with the setuid and setgid syscalls  However  ordinarily when a program does this  it loses its set of capabilities - this is so that the old way of dropping root with setuid still works  The --keep 1 flag tells capsh to issue the prctl PR SET KEEPCAPS  syscall  which disables the dropping of capabilities when changing user  The actual changing of users by capsh happens with the --user flag  which runs setuid and setgid   The next problem we need to solve is how to set capabilities in a way that carries on after we exec our children  The capabilities system has always had an  inherited  set of capabilities  which is   a set of capabilities preserved across an execve 2    capabilities 7    Whilst this sounds like it solves our problem  just set the cap net bind service capability to inherited  right    this actually only applies for privileged processes - and our process is not privileged anymore  because we already changed user  with the --user flag     The new ambient capability set works around this problem - it is  a set of capabilities that are preserved across an execve 2  of a program that is not privileged   By putting cap net bind service in the ambient set  when capsh exec s our server program  our program will inherit this capability and be able to bind listeners to low ports   If you re interested to learn more  the capabilities manual page explains this in great detail  Running capsh through strace is also very informative

User · Answer

TLDR  For  the answer   as I see it   jump down to the   TLDR lt  lt  part in this answer   OK  I ve figured it out  for real this time   the answer to this question  and this answer of mine is also a way of apologizing for promoting another answer  both here and on twitter  that I thought was  the best   but after trying it  discovered that I was mistaken about that  Learn from my mistake kids  don t promote something until you ve actually tried it yourself   Again  I reviewed all the answers here  I ve tried some of them  and chose not to try others because I simply didn t like the solutions   I thought that the solution was to use systemd with its Capabilities  and CapabilitiesBindingSet  settings  After wrestling with this for some time  I discovered that this is not the solution because   Capabilities are intended to restrict root processes   As the OP wisely stated  it is always best to avoid that  for all your daemons if possible     You cannot use the Capabilities related options with User  and Group  in systemd unit files  because capabilities are ALWAYS reset when execev  or whatever the function is  is called  In other words  when systemd forks and drops its perms  the capabilities are reset  There is no way around this  and all that binding logic in the kernel is basic around uid 0  not capabilities  This means that it is unlikely that Capabilities will ever be the right answer to this question  at least any time soon   Incidentally  setcap  as others have mentioned  is not a solution  It didn t work for me  it doesn t work nicely with scripts  and those are reset anyways whenever the file changes   In my meager defense  I did state  in the comment I ve now deleted   that James  iptables suggestion  which the OP also mentions   was the  2nd best solution    -P    TLDR lt  lt   The solution is to combine systemd with on-the-fly iptables commands  like this  taken from DNSChain     Unit  Description dnschain After network target Wants namecoin service   Service  ExecStart  usr local bin dnschain Environment DNSCHAIN SYSD VER 0 0 1 PermissionsStartOnly true ExecStartPre  sbin sysctl -w net ipv4 ip forward 1 ExecStartPre - sbin iptables -D INPUT -p udp --dport 5333 -j ACCEPT ExecStartPre - sbin iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333 ExecStartPre  sbin iptables -A INPUT -p udp --dport 5333 -j ACCEPT ExecStartPre  sbin iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333 ExecStopPost  sbin iptables -D INPUT -p udp --dport 5333 -j ACCEPT ExecStopPost  sbin iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333 User dns Group dns Restart always RestartSec 5 WorkingDirectory  home dns PrivateTmp true NoNewPrivileges true ReadOnlyDirectories  etc    Unfortunately  capabilities are basically worthless because they re designed to restrict root daemons  Instead  we use iptables to listen on privileged ports    Capabilities cap net bind service pei   SecureBits keep-caps   Install  WantedBy multi-user target   Here we accomplish the following    The daemon listens on 5333  but connections are successfully accepted on 53 thanks to iptables We can include the commands in the unit file itself  and thus we save people headaches  systemd cleans up the firewall rules for us  making sure to remove them when the daemon isn t running  We never run as root  and we make privilege escalation impossible  at least systemd claims to   supposedly even if the daemon is compromised and sets uid 0    iptables is still  unfortunately  quite an ugly and difficult-to-use utility  If the daemon is listening on eth0 0 instead of eth0  for example  the commands are slightly different

User · Answer

For some reason no one mention about lowering sysctl net ipv4 ip unprivileged port start to the value you need  Example  We need to bind our app to 443 port   sysctl net ipv4 ip unprivileged port start 443   Some may say  there is a potential security problem  unprivileged users now may bind to the other privileged ports  444-1024   But you can solve this problem easily with iptables  by blocking other ports   iptables -I INPUT -p tcp --dport 444 1024 -j DROP iptables -I INPUT -p udp --dport 444 1024 -j DROP   Comparison with other methods  This method    from some point is  IMO  even more secure than setting CAP NET BIND SERVICE setuid  since an application doesn t setuid at all  even partly  capabilities actually are   For example  to catch a coredump of capability-enabled application you will need to change sysctl fs suid dumpable  which leads to another potential security problems  Also  when CAP suid is set   proc PID directory is owned by root  so your non-root user will not have full information control of running process  for example  user will not be able  in common case  to determine which connections belong to application via  proc PID fd   netstat -aptn   grep PID   has security disadvantage  while your app  or any app that uses ports 443-1024  is down for some reason  another app could take the port  But this problem could also be applied to CAP suid  in case you set it on interpreter  e g  java nodejs  and iptables-redirect  Use systemd-socket method to exclude this problem  Use authbind method to only allow special user binding  doesn t require setting CAP suid every time you deploy new version of application  doesn t require application support modification  like systemd-socket method  doesn t require kernel rebuild  if running version supports this sysctl setting  doesn t do LD PRELOAD like authbind privbind method  this could potentially affect performance  security  behavior  does it  haven t tested   In the rest authbind is really flexible and secure method  over-performs iptables REDIRECT DNAT method  since it doesn t require address translation  connection state tracking  etc  This only noticeable on high-load systems    Depending on the situation  I would choose between sysctl  CAP  authbind and iptables-redirect  And this is great that we have so many options

User · Answer

File capabilities are not ideal  because they can break after a package update   The ideal solution  IMHO  should be an ability to create a shell with inheritable CAP NET BIND SERVICE set   Here s a somewhat convoluted way to do this   sg  DAEMONUSER  capsh --keep 1 --uid  id -u  DAEMONUSER         --caps  cap net bind service pei  --        YOUR COMMAND GOES HERE    capsh utility can be found in libcap2-bin package in Debian Ubuntu distributions  Here s what goes on    sg changes effective group ID to that of the daemon user  This is necessary because capsh leaves GID unchanged and we definitely do not want it  Sets bit  keep capabilities on UID change   Changes UID to  DAEMONUSER Drops all caps  at this moment all caps are still present because of --keep 1   except inheritable cap net bind service Executes your command   --  is a separator    The result is a process with specified user and group  and cap net bind service privileges   As an example  a line from ejabberd startup script   sg  EJABBERDUSER  capsh --keep 1 --uid  id -u  EJABBERDUSER  --caps  cap net bind service pei  --  EJABBERD --noshell -detached

User · Answer

I tried the iptables PREROUTING REDIRECT method  In older kernels it seems this type of rule wasn t supported for IPv6  But apparently it is now supported in ip6tables v1 4 18 and Linux kernel v3 8   I also found that PREROUTING REDIRECT doesn t work for connections initiated within the machine  To work for conections from the local machine  add an OUTPUT rule also     see iptables port redirect not working for localhost  E g  something like   iptables -t nat -I OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080   I also found that PREROUTING REDIRECT also affects forwarded packets  That is  if the machine is also forwarding packets between interfaces  e g  if it s acting as a Wi-Fi access point connected to an Ethernet network   then the iptables rule will also catch connected clients  connections to Internet destinations  and redirect them to the machine  That s not what I wanted   I only wanted to redirect connections that were directed to the machine itself  I found I can make it only affect packets addressed to the box  by adding -m addrtype --dst-type LOCAL  E g  something like   iptables -A PREROUTING -t nat -p tcp --dport 80 -m addrtype --dst-type LOCAL -j REDIRECT --to-port 8080   One other possibility is to use TCP port forwarding  E g  using socat   socat TCP4-LISTEN www reuseaddr fork TCP4 localhost 8080   However one disadvantage with that method is  the application that is listening on port 8080 then doesn t know the source address of incoming connections  e g  for logging or other identification purposes

User · Answer

Answer at 2015 Sep   ip6tables now supports IPV6 NAT  http   www netfilter org projects iptables files changes-iptables-1 4 17 txt  You will need kernel 3 7   Proof    09 09 23  root X   ip6tables -t nat -vnL Chain PREROUTING  policy ACCEPT 0 packets  0 bytes   pkts bytes target     prot opt in     out     source               destination     0     0 REDIRECT   tcp      eth0              0                    0                 tcp dpt 80 redir ports 8080     0     0 REDIRECT   tcp      eth0              0                    0                 tcp dpt 443 redir ports 1443  Chain INPUT  policy ACCEPT 0 packets  0 bytes   pkts bytes target     prot opt in     out     source               destination  Chain OUTPUT  policy ACCEPT 6148 packets  534K bytes   pkts bytes target     prot opt in     out     source               destination  Chain POSTROUTING  policy ACCEPT 6148 packets  534K bytes   pkts bytes target     prot opt in     out     source               destination

User · Answer

Linux supports capabilities to support more fine-grained permissions than just  this application is run as root   One of those capabilities is CAP NET BIND SERVICE which is about binding to a privileged port   lt 1024    Unfortunately I don t know how to exploit that to run an application as non-root while still giving it CAP NET BIND SERVICE  probably using setcap  but there s bound to be an existing solution for this

User · Answer

Or patch your kernel and remove the check    Option of last resort  not recommended    In net ipv4 af inet c  remove the two lines that read        if  snum  amp  amp  snum  lt  PROT SOCK  amp  amp   capable CAP NET BIND SERVICE                 goto out    and the kernel won t check privileged ports anymore

User · Answer

Update 2017  Use authbind  Much better than CAP NET BIND SERVICE or a custom kernel     CAP NET BIND SERVICE grants trust to the binary but provides no control over per-port access    Authbind grants trust to the user group and provides control over per-port access  and supports both IPv4 and IPv6  IPv6 support has been added as of late     Install  apt-get install authbind Configure access to relevant ports  e g  80 and 443 for all users and groups      sudo touch  etc authbind byport 80   sudo touch  etc authbind byport 443   sudo chmod 777  etc authbind byport 80   sudo chmod 777  etc authbind byport 443  Execute your command via authbind  optionally specifying --deep or other arguments  see the man page    authbind --deep  path to binary command line args   e g     authbind --deep java -jar SomeServer jar       As a follow-up to Joshua s fabulous   not recommended unless you know what you do  recommendation to hack the kernel   I ve first posted it here   Simple  With a normal or old kernel  you don t   As pointed out by others  iptables can forward a port   As also pointed out by others  CAP NET BIND SERVICE can also do the job    Of course CAP NET BIND SERVICE will fail if you launch your program from a script  unless you set the cap on the shell interpreter  which is pointless  you could just as well run your service as root      e g  for Java  you have to apply it to the JAVA JVM  sudo  sbin setcap  cap net bind service ep   usr lib jvm java-8-openjdk jre bin java   Obviously  that then means any Java program can bind system ports  Dito for mono  NET   I m also pretty sure xinetd isn t the best of ideas   But since both methods are hacks  why not just lift the limit by lifting the restriction    Nobody said you have to run a normal kernel  so you can just run your own    You just download the source for the latest kernel  or the same you currently have   Afterwards  you go to    usr src linux- lt version number gt  include net sock h    There you look for this line     Sockets 0-1023 can t be bound to unless you are superuser     define PROT SOCK       1024   and change it to    define PROT SOCK 0   if you don t want to have an insecure ssh situation  you alter it to this       define PROT SOCK 24  Generally  I d use the lowest setting that you need  e g 79 for http  or 24 when using SMTP on port 25   That s already all   Compile the kernel  and install it   Reboot  Finished - that stupid limit is GONE  and that also works for scripts   Here s how you compile a kernel   https   help ubuntu com community Kernel Compile    You can get the kernel-source via package linux-source  no manual download required apt-get install linux-source fakeroot  mkdir   src cd   src tar xjvf  usr src linux-source- lt version gt  tar bz2 cd linux-source- lt version gt     Apply the changes to PROT SOCK define in  include net sock h    Copy the kernel config file you are currently using cp -vi  boot config- uname -r   config    Install ncurses libary  if you want to run menuconfig apt-get install libncurses5 libncurses5-dev    Run menuconfig  optional  make menuconfig    Define the number of threads you wanna use when compiling  should be  lt number CPU cores gt  - 1   e g  for quad-core export CONCURRENCY LEVEL 3   Now compile the custom kernel fakeroot make-kpkg --initrd --append-to-version custom kernel-image kernel-headers    And wait a long long time  cd      In a nutshell  use iptables if you want to stay secure  compile the kernel if you want to be sure this restriction never bothers you again

User · Answer

Update 2017  Use authbind  Much better than CAP NET BIND SERVICE or a custom kernel     CAP NET BIND SERVICE grants trust to the binary but provides no control over per-port access    Authbind grants trust to the user group and provides control over per-port access  and supports both IPv4 and IPv6  IPv6 support has been added as of late     Install  apt-get install authbind Configure access to relevant ports  e g  80 and 443 for all users and groups      sudo touch  etc authbind byport 80   sudo touch  etc authbind byport 443   sudo chmod 777  etc authbind byport 80   sudo chmod 777  etc authbind byport 443  Execute your command via authbind  optionally specifying --deep or other arguments  see the man page    authbind --deep  path to binary command line args   e g     authbind --deep java -jar SomeServer jar       As a follow-up to Joshua s fabulous   not recommended unless you know what you do  recommendation to hack the kernel   I ve first posted it here   Simple  With a normal or old kernel  you don t   As pointed out by others  iptables can forward a port   As also pointed out by others  CAP NET BIND SERVICE can also do the job    Of course CAP NET BIND SERVICE will fail if you launch your program from a script  unless you set the cap on the shell interpreter  which is pointless  you could just as well run your service as root      e g  for Java  you have to apply it to the JAVA JVM  sudo  sbin setcap  cap net bind service ep   usr lib jvm java-8-openjdk jre bin java   Obviously  that then means any Java program can bind system ports  Dito for mono  NET   I m also pretty sure xinetd isn t the best of ideas   But since both methods are hacks  why not just lift the limit by lifting the restriction    Nobody said you have to run a normal kernel  so you can just run your own    You just download the source for the latest kernel  or the same you currently have   Afterwards  you go to    usr src linux- lt version number gt  include net sock h    There you look for this line     Sockets 0-1023 can t be bound to unless you are superuser     define PROT SOCK       1024   and change it to    define PROT SOCK 0   if you don t want to have an insecure ssh situation  you alter it to this       define PROT SOCK 24  Generally  I d use the lowest setting that you need  e g 79 for http  or 24 when using SMTP on port 25   That s already all   Compile the kernel  and install it   Reboot  Finished - that stupid limit is GONE  and that also works for scripts   Here s how you compile a kernel   https   help ubuntu com community Kernel Compile    You can get the kernel-source via package linux-source  no manual download required apt-get install linux-source fakeroot  mkdir   src cd   src tar xjvf  usr src linux-source- lt version gt  tar bz2 cd linux-source- lt version gt     Apply the changes to PROT SOCK define in  include net sock h    Copy the kernel config file you are currently using cp -vi  boot config- uname -r   config    Install ncurses libary  if you want to run menuconfig apt-get install libncurses5 libncurses5-dev    Run menuconfig  optional  make menuconfig    Define the number of threads you wanna use when compiling  should be  lt number CPU cores gt  - 1   e g  for quad-core export CONCURRENCY LEVEL 3   Now compile the custom kernel fakeroot make-kpkg --initrd --append-to-version custom kernel-image kernel-headers    And wait a long long time  cd      In a nutshell  use iptables if you want to stay secure  compile the kernel if you want to be sure this restriction never bothers you again

User · Answer

Linux supports capabilities to support more fine-grained permissions than just  this application is run as root   One of those capabilities is CAP NET BIND SERVICE which is about binding to a privileged port   lt 1024    Unfortunately I don t know how to exploit that to run an application as non-root while still giving it CAP NET BIND SERVICE  probably using setcap  but there s bound to be an existing solution for this

User · Answer

Okay  thanks to the people who pointed out the capabilities system and CAP NET BIND SERVICE capability  If you have a recent kernel  it is indeed possible to use this to start a service as non-root but bind low ports  The short answer is that you do   setcap  cap net bind service  ep   path to program   And then anytime program is executed thereafter it will have the CAP NET BIND SERVICE capability  setcap is in the debian package libcap2-bin   Now for the caveats    You will need at least a 2 6 24 kernel This won t work if your file is a script   ie  uses a    line to launch an interpreter   In this case  as far I as understand  you d have to apply the capability to the interpreter executable itself  which of course is a security nightmare  since any program using that interpreter will have the capability  I wasn t able to find any clean  easy way to work around this problem  Linux will disable LD LIBRARY PATH on any program that has elevated privileges like setcap or suid   So if your program uses its own     lib   you might have to look into another option like port forwarding    Resources    capabilities 7  man page  Read this long and hard if you re going to use capabilities in a production environment  There are some really tricky details of how capabilities are inherited across exec   calls that are detailed here  setcap man page  Bind ports below 1024 without root on GNU Linux   The document that first pointed me towards setcap    Note  RHEL first added this in v6

User · Answer

The standard way is to make them  setuid  so that they start up as root  and then they throw away that root privilege as soon as they ve bound to the port but before they start accepting connections to it   You can see good examples of that in the source code for Apache and INN   I m told that Lighttpd is another good example   Another example is Postfix  which uses multiple daemons that communicate through pipes  and only one or two of them  which do very little except accept or emit bytes  run as root and the rest run at a lower privilege

User · Answer

I know this is an old question  but now with recent     4 3  kernels there is finally a good answer to this - ambient capabilities   The quick answer is to grab a copy of the latest  as-yet-unreleased  version of libcap from git and compile it  Copy the resulting progs capsh binary somewhere   usr local bin is a good choice   Then  as root  start your program with   usr local bin capsh --keep 1 --user  your-service-user-name        --inh  cap net bind service  --addamb  cap net bind service         -- -c  your-program    In order  we are   Declaring that when we switch users  we want to keep our current capability sets Switching user  amp  group to  your-service-user-name  Adding the cap net bind service capability to the inherited  amp  ambient sets Forking bash -c  your-command   since capsh automatically starts bash with the arguments after --    There s a lot going on under the hood here   Firstly  we are running as root  so by default  we get a full set of capabilities  Included in this is the ability to switch uid  amp  gid with the setuid and setgid syscalls  However  ordinarily when a program does this  it loses its set of capabilities - this is so that the old way of dropping root with setuid still works  The --keep 1 flag tells capsh to issue the prctl PR SET KEEPCAPS  syscall  which disables the dropping of capabilities when changing user  The actual changing of users by capsh happens with the --user flag  which runs setuid and setgid   The next problem we need to solve is how to set capabilities in a way that carries on after we exec our children  The capabilities system has always had an  inherited  set of capabilities  which is   a set of capabilities preserved across an execve 2    capabilities 7    Whilst this sounds like it solves our problem  just set the cap net bind service capability to inherited  right    this actually only applies for privileged processes - and our process is not privileged anymore  because we already changed user  with the --user flag     The new ambient capability set works around this problem - it is  a set of capabilities that are preserved across an execve 2  of a program that is not privileged   By putting cap net bind service in the ambient set  when capsh exec s our server program  our program will inherit this capability and be able to bind listeners to low ports   If you re interested to learn more  the capabilities manual page explains this in great detail  Running capsh through strace is also very informative

User · Answer

systemd is a sysvinit replacement which has an option to launch a daemon with specific capabilities  Options Capabilities   CapabilityBoundingSet  in systemd exec 5  manpage

User · Answer

You can setup a local SSH tunnel  eg if you want port 80 to hit your app bound to 3000   sudo ssh  USERNAME localhost -L 80 localhost 3000 -N   This has the advantage of working with script servers  and being very simple

User · Answer

Or patch your kernel and remove the check    Option of last resort  not recommended    In net ipv4 af inet c  remove the two lines that read        if  snum  amp  amp  snum  lt  PROT SOCK  amp  amp   capable CAP NET BIND SERVICE                 goto out    and the kernel won t check privileged ports anymore

User · Answer

Two other simple possibilities   There is an old  unfashionable  solution to the  a daemon that binds on a low port and hands control to your daemon   It s called inetd  or xinetd   The cons are    your daemon needs to talk on stdin stdout  if you don t control the daemon -- if you don t have the source -- then this is perhaps a showstopper  although some services may have an inetd-compatibility flag  a new daemon process is forked for every connection it s one extra link in the chain   Pros    available on any old UNIX once your sysadmin has set up the config  you re good to go about your development  when you re-build your daemon  might you lose setcap capabilities  And then you ll have to go back to your admin  please sir      daemon doesn t have to worry about that networking stuff  just has to talk on stdin stdout can configure to execute your daemon as a non-root user  as requested   Another alternative  a hacked-up proxy  netcat or even something more robust  from the privileged port to some arbitrary high-numbered port where you can run your target daemon   Netcat is obviously not a production solution  but  just my dev box   right    This way you could continue to use a network-capable version of your server  would only need root sudo to start proxy  at boot   wouldn t be relying on complex potentially fragile capabilities

User · Answer

For some reason no one mention about lowering sysctl net ipv4 ip unprivileged port start to the value you need  Example  We need to bind our app to 443 port   sysctl net ipv4 ip unprivileged port start 443   Some may say  there is a potential security problem  unprivileged users now may bind to the other privileged ports  444-1024   But you can solve this problem easily with iptables  by blocking other ports   iptables -I INPUT -p tcp --dport 444 1024 -j DROP iptables -I INPUT -p udp --dport 444 1024 -j DROP   Comparison with other methods  This method    from some point is  IMO  even more secure than setting CAP NET BIND SERVICE setuid  since an application doesn t setuid at all  even partly  capabilities actually are   For example  to catch a coredump of capability-enabled application you will need to change sysctl fs suid dumpable  which leads to another potential security problems  Also  when CAP suid is set   proc PID directory is owned by root  so your non-root user will not have full information control of running process  for example  user will not be able  in common case  to determine which connections belong to application via  proc PID fd   netstat -aptn   grep PID   has security disadvantage  while your app  or any app that uses ports 443-1024  is down for some reason  another app could take the port  But this problem could also be applied to CAP suid  in case you set it on interpreter  e g  java nodejs  and iptables-redirect  Use systemd-socket method to exclude this problem  Use authbind method to only allow special user binding  doesn t require setting CAP suid every time you deploy new version of application  doesn t require application support modification  like systemd-socket method  doesn t require kernel rebuild  if running version supports this sysctl setting  doesn t do LD PRELOAD like authbind privbind method  this could potentially affect performance  security  behavior  does it  haven t tested   In the rest authbind is really flexible and secure method  over-performs iptables REDIRECT DNAT method  since it doesn t require address translation  connection state tracking  etc  This only noticeable on high-load systems    Depending on the situation  I would choose between sysctl  CAP  authbind and iptables-redirect  And this is great that we have so many options

User · Answer

My  standard workaround  uses socat as the user-space redirector   socat tcp6-listen 80 fork tcp6 8080   Beware that this won t scale  forking is expensive but it s the way socat works

User · Answer

Linux supports capabilities to support more fine-grained permissions than just  this application is run as root   One of those capabilities is CAP NET BIND SERVICE which is about binding to a privileged port   lt 1024    Unfortunately I don t know how to exploit that to run an application as non-root while still giving it CAP NET BIND SERVICE  probably using setcap  but there s bound to be an existing solution for this

User · Answer

At startup   iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080   Then  you can bind to the port you forward to

User · Answer

Two other simple possibilities   There is an old  unfashionable  solution to the  a daemon that binds on a low port and hands control to your daemon   It s called inetd  or xinetd   The cons are    your daemon needs to talk on stdin stdout  if you don t control the daemon -- if you don t have the source -- then this is perhaps a showstopper  although some services may have an inetd-compatibility flag  a new daemon process is forked for every connection it s one extra link in the chain   Pros    available on any old UNIX once your sysadmin has set up the config  you re good to go about your development  when you re-build your daemon  might you lose setcap capabilities  And then you ll have to go back to your admin  please sir      daemon doesn t have to worry about that networking stuff  just has to talk on stdin stdout can configure to execute your daemon as a non-root user  as requested   Another alternative  a hacked-up proxy  netcat or even something more robust  from the privileged port to some arbitrary high-numbered port where you can run your target daemon   Netcat is obviously not a production solution  but  just my dev box   right    This way you could continue to use a network-capable version of your server  would only need root sudo to start proxy  at boot   wouldn t be relying on complex potentially fragile capabilities

User · Answer

I tried the iptables PREROUTING REDIRECT method  In older kernels it seems this type of rule wasn t supported for IPv6  But apparently it is now supported in ip6tables v1 4 18 and Linux kernel v3 8   I also found that PREROUTING REDIRECT doesn t work for connections initiated within the machine  To work for conections from the local machine  add an OUTPUT rule also     see iptables port redirect not working for localhost  E g  something like   iptables -t nat -I OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080   I also found that PREROUTING REDIRECT also affects forwarded packets  That is  if the machine is also forwarding packets between interfaces  e g  if it s acting as a Wi-Fi access point connected to an Ethernet network   then the iptables rule will also catch connected clients  connections to Internet destinations  and redirect them to the machine  That s not what I wanted   I only wanted to redirect connections that were directed to the machine itself  I found I can make it only affect packets addressed to the box  by adding -m addrtype --dst-type LOCAL  E g  something like   iptables -A PREROUTING -t nat -p tcp --dport 80 -m addrtype --dst-type LOCAL -j REDIRECT --to-port 8080   One other possibility is to use TCP port forwarding  E g  using socat   socat TCP4-LISTEN www reuseaddr fork TCP4 localhost 8080   However one disadvantage with that method is  the application that is listening on port 8080 then doesn t know the source address of incoming connections  e g  for logging or other identification purposes

User · Answer

Or patch your kernel and remove the check    Option of last resort  not recommended    In net ipv4 af inet c  remove the two lines that read        if  snum  amp  amp  snum  lt  PROT SOCK  amp  amp   capable CAP NET BIND SERVICE                 goto out    and the kernel won t check privileged ports anymore

User · Answer

systemd is a sysvinit replacement which has an option to launch a daemon with specific capabilities  Options Capabilities   CapabilityBoundingSet  in systemd exec 5  manpage

User · Answer

With systemd  you just need to slightly modify your service to accept preactivated sockets   You can later use systemd socket activate   No capabilities  iptables or other tricks are needed   This is content of relevant systemd files from this example of simple python http server  File httpd-true service   Unit  Description Httpd true    Service  ExecStart  usr local bin httpd-true User subsonic  PrivateTmp yes   File httpd-true socket   Unit  Description HTTPD true   Socket  ListenStream 80   Install  WantedBy default target

User · Answer

Modern Linux supports  sbin sysctl -w net ipv4 ip unprivileged port start 0

[linux] Is there a way for non-root processes to bind to "privileged" ports on Linux?

Examples related to linux

Examples related to root

Examples related to ipv6

Examples related to iptables

Examples related to linux-capabilities