Linux Capabilities and rsync, from presentation to practice

Hazel Smith gave an excellent talk at FLOSSUK’s Unconference in London about Linux Capabilities and using them as part of “least privilege” when running backups of Linux systems.

Hazel explained that by using Capabilities you can allow a single user (in this example backuphelper) when running a single binary (rsync) to read any file on the system. Hazel stressed in the presentation that this isn’t a privilege to give out lightly, however the ability to read any file isn’t a direct path to root. This level of privilege will allow access to for example hashed passwords or contents of any user’s files.

My personal backups use BackupPC which can pull backups with tar, smbclient or as I use rsync over ssh.

The second half of this post documents how I put Hazel’s talk into practice on my Debian based systems. I have also uploaded to GitHub an example Ansible task I used to roll out the changes to my systems.

Target System Setup

First off install the support packages for capabilities.

sudo apt-get install libcap2-bin libpam-cap
sudo pam-auth-update

Run  pam-auth-update and enable “Inheritable Capabilities Management”, if you prefer to manually manage the pam config files then add the line “auth optional” to /etc/pam.d/common-auth

You will also need to add following line to /etc/security/capability.conf to allow backuphelper to retain cap_dac_read_search. The rules applied in order so make sure it’s above the default deny line “none  *”

cap_dac_read_search backuphelper

This next command sets cap_dac_read_search as Inheritable and Effective for the rsync binary. The net effect is that when the backuphelper user runs rsync that process can read any file on the system.

sudo setcap cap_dac_read_search+ei /usr/bin/rsync

The “belt and braces” setup Hazel recommended both locking down ssh access for the backuphelper user to ssh-keys only and locking the password on the account. To follow this advice add the following lines to /etc/ssh/sshd_config.

Match User backuphelper
 PasswordAuthentication no

And run the following command to lock the backuphelper account’s password

sudo passwd -l backuphelper

BackupPC Server Setup

The change needed here is very simple, you only need to change the user that pulls backups from your other systems. You will need to ensure that you have correctly setup the ssh keys etc for the backuphelper user.

This can be done either via the web UI or by editing the .pl config file directly. You need to change “-l root” to “-l backuphelper” for the RsyncClientCmd. An example from one of my systems is

$Conf{RsyncClientCmd} = '$sshPath -q -x -l backuphelper $host $rsyncPath $argList+';


Always be careful working with PAM, you can lock yourself out! It is worth having a root shell open “just in case” until you are familiar with the process.

A simple test is to login via ssh as backuphelper and run “rsync -avn /root” and you shouldn’t get any permission denied errors and should see a list of files.

Something to bear in mind when debugging this is that running sudo from root -> user doesn’t give the user capabilities, you need to login directly to test things.

If you want to see whether pam_cap is working when logged in you can do this:

grep CapInh /proc/$$/status

Use capsh –decode= on the resulting bit string to understand what permissions you’ve got.

/etc/crypttab, Systemd and keyscripts

I’ve upgraded some of my systems to Ubuntu 15.04 and found that some system didn’t boot due to poorly documented interactions between Systemd and /etc/crypttab.

The major bug is around keyscripts, Debian and Ubuntu have for a long time supported using a binary or script to provide a password for encrypted devices, from the Debian crypttab man page:

keyscript= The executable at the indicated path is executed with the key file from the third field of the crypttab as its only argument and the output is used as the key.

People have used this for all sorts of creative ways of getting passwords from TPM chips, cryptocards etc.

The root of the problem is that systemd doesn’t support keyscripts at all, and in fact doesn’t even parse /etc/crypttab on boot.

I have worked round this bug by moving all my keyscript dependant volumes to start post system boot. The command cryptdisks_start still uses /etc/crypttab and keyscripts correctly, so I have added either nofail or noauto options to the devices in /etc/fstab and /etc/crypttab to allow the system to boot.

Another minor bug I encountered was caused by using the system UUID as a simple password for my backup disk. While this isn’t the worlds most secure key it is unique to my laptop and accessible to the system without any user interaction.

I did this by setting keyfile in /etc/crypttab to /sys/class/dmi/id/product_uuid. The bug is that systemd interprets the /sys path and for reasons I’ve not looked at in depth doesn’t start the LUKS device. The simple fix is to change the keyfile path and symlink the /sys file to the new location ie:

 sudo ln -s /sys/class/dmi/id/product_uuid /boot/uuid



Enabling ssh support in gpg-agent on Ubuntu

I recently replaced my old Yubikey with one of the new Yubikey NEO’s, I wanted a simple and secure way of storing my GPG key as well 2 factor authentication.

This post is about setting up and fixing Ubuntu 14.04 and 14.10 to enable ssh-agent functionality in gpg-agent. I assume that you have already securely generated and stored a gpg key in the Yubikey and have imported the key stubs into gpg.

This post is rather complex because Seahorse the gnome-keyring manager “supports” ssh and gpg agent type functionality and takes over ssh-agent and gpg-agent. The problem with Seahorse is that it doesn’t work with OpenPGP cards and a secondary problem is that you need to disable a number of other ssh key services.

First you will need to install the following packages, gnupg-agent and pcscd the smart card management service.

sudo apt-get install gnupg-agent pcscd

You need to disable gnome-keyring’s ssh and gpg agent functionality, bug id 1387303 contains a fix allow this which has now been released as gnome-keyring – 3.10.1-1ubuntu7.1. Once this is installed you can disable the ssh and gpg agents in Unity’s startup applications found under the settings menu.

You will need to enable both gpg-agent support in gpg and then ssh-agent support in gpg-agent. In the $HOME/.gnupg directory add the line use-agent to gpg.conf  and enable-ssh-support gpg-agent.conf you may need to create the files.

Next you need to install a fixed version of the gnupg-agent upstart init script so that it starts gpg-agent correctly with ssh key support. Install this script into the .init directory in your home directory this overrides the system wide one.

mkdir $HOME/.init
wget -O $HOME/.init/gnupg-agent.conf

Finally you need to disable the “real” ssh-agent by commenting out the line in /etc/X11/Xsession.options, there aren’t any override options that I know of.

After restarting X or a reboot you should find that ssh-agent -L prints out a long ssh key string, you are looking for the one that ends in card:XXXXX this is the public half of your Yubikey gpg key in ssh key format.

With gnupg-agent providing ssh-agent services, you can use ssh-add to import existing SSH private keys into gpg’s key secure storage.

Hints and methods taken from: