RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

[Steve Langasek]

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 at ubuntu.com                                     vorlon at debian.org

[1] https://github.com/opencontainers/image-spec/issues/725
[2] https://github.com/lxc/lxd/issues/4862
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20180801/af02f3cd/attachment.sig>