Linux – Preserve Linux Capabilities in Debian Package

deblinuxpermissions

I'm building a package containing a web service that needs to listen on port 443. The service itself is written in Go, so I can't use authbind to manage the port permissions. Instead, I've opted to use setcap:

me@buildbox $ setcap CAP_NET_BIND_SERVICE=+eip opt/myservice/myservice
me@buildbox $ getcap opt/myservice/myservice
opt/myservice/myservice = cap_net_bind_service+eip

However, this capability is not preserved when I install the package on my servers.

me@myserver $ apt-get install myservice
...
# installs normally
...
me@myserver $ getcap /opt/myservice/myservice
me@myserver $ # ^ No output == no capabilities

I really don't want this service to be run as root ever, but I'm having trouble coming up with a solution that is preserved when the package is installed. Can I somehow set capabilities in a debian package? Is there another method that achieves the desired end result (service can bind to port 443, but doesn't run as root).

Best Answer

User Zoredache answered this in the comments. I'm posting this answer to make sure that people finding this question are aware that the problem was resolved.

In the debian package, I added a postinst file to DEBIAN/, which dpkg executes after copying files to the filesystem. The postinst contains the following:

#!/bin/sh
set -e
setcap CAP_NET_BIND_SERVICE=+eip /opt/myservice/myservice

This worked for me. I don't remember now, but I believe the package did need to be installed by a user with sudo access on the destination machine.

Related Solutions

Linux – How to run a server on port 80 as a normal user on Linux

Short answer: you can't. Ports below 1024 can be opened only by root. As per comment - well, you can, using CAP_NET_BIND_SERVICE, but that approach, applied to java bin will make any java program to be run with this setting, which is undesirable, if not a security risk.

The long answer: you can redirect connections on port 80 to some other port you can open as normal user.

Run as root:

# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

As loopback devices (like localhost) do not use the prerouting rules, if you need to use localhost, etc., add this rule as well (thanks @Francesco):

# iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080

NOTE: The above solution is not well suited for multi-user systems, as any user can open port 8080 (or any other high port you decide to use), thus intercepting the traffic. (Credits to CesarB).

EDIT: as per comment question - to delete the above rule:

# iptables -t nat --line-numbers -n -L

This will output something like:

Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:8080 redir ports 8088
2    REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 redir ports 8080

The rule you are interested in is nr. 2, so to delete it:

# iptables -t nat -D PREROUTING 2

Linux – n00bie Linode VPS – am I reasonably secure? How to audit

It sounds like you're on the right track. If you end up getting compromised, it's most likely that it'll happen through vulnerabilities in your application software (you mentioned Wordpress and Drupal). To mitigate these risks, you need to keep abreast of any vulnerability announcements for those products (including any plugins/modules you have installed), and install patches as soon as possible.

Additionally, set up a bullet-proof backup system for the server and do test restores regularly. If you do get compromised, you're going to need to do a complete re-install of your server and data. If you have a good backup system, this process is much less painful.

Best Answer

Related Solutions

Linux – How to run a server on port 80 as a normal user on Linux

Linux – n00bie Linode VPS – am I reasonably secure? How to audit

Related Topic