Wednesday 1 August 2018

RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

A recent customer bug report revealed that we have packages in the standard
Ubuntu system (mtr-tiny) which are making use of filesystem capabilities, to
reduce the need for suid binaries on the system:

$ getcap /usr/bin/mtr-packet
/usr/bin/mtr-packet = cap_net_raw+ep
$

The customer bug report arose because today, we are not handling all Ubuntu
images in an xattr-safe manner. E.g., on a freshly-launched cosmic lxd
container here:

$ lxc exec caring-calf -- getcap /usr/bin/mtr-packet
$

This prevents the software from working as intended by the Debian
maintainer; the command will only succeed as root in such an environment,
where it is intended to be runnable as a non-root user.

We have previously dealt with such an incompatibility in the iputils package
by introducing an Ubuntu delta
(https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1302192), restoring
use of suid in place of fscaps. This is suboptimal because:

- It violates the principle of least privilege; why give processes full
root privs if cap_net_raw is all they need?
- It's a game of whack-a-mole. We fixed iputils in response to bug
reports, but the wrong privileges on mtr-packet went unnoticed. There
may be other bugs in the future again caused by failing to preserve
xattrs.

I am therefore proposing that we explicitly raise the requirements for
Ubuntu root filesystems to always be transported in an xattr-preserving
manner.

This will require bugfixes in various places, but ideally on a one-time
basis only. The primary areas of concern are:

- Where root filesystems are distributed as tarballs, they are not
currently created with --xattrs; this will need to be changed.
- Users who are unpacking root tarballs need to take care to pass
--xattrs-include=* to tar.
- Users who are backing up or streaming Ubuntu root filesystems with tar or
rsync will need to take care to pass non-default xattr-preserving options
(tar --xattrs; rsync -X).
- GNU tar's xattrs format incompatible with other unpack implementations
(e.g. libarchive)[1]. Anyone using another unpacker will necessarily
end up without fscaps.
- lxd will require some additional work in order for fscaps to work as
expected in unprivileged containers[2].

The parts of this that require changes to Ubuntu seem doable within the
18.10 timeframe, and backportable to 18.04 (where the handling of mtr-tiny
is also buggy), after which we could drop the Ubuntu delta for iputils.

The parts of this that involve changes to user behavior are less
controllable; hence raising visibility on this question in a public forum.

Thoughts?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

[1] https://github.com/opencontainers/image-spec/issues/725
[2] https://github.com/lxc/lxd/issues/4862