RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Steve Langasek-6
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/
[hidden email]                                     [hidden email]

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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Colin Watson
On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:
>  - Users who are unpacking root tarballs need to take care to pass
>    --xattrs-include=* to tar.

The tar documentation suggests that just --xattrs should be enough:

  By default, when '--xattr' is used, all names are stored in the
  archive (or extracted, if using '--extract').

Am I missing something?

--
Colin Watson                                       [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Steve Langasek-6
On Thu, Aug 02, 2018 at 01:22:07PM +0100, Colin Watson wrote:
> On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:
> >  - Users who are unpacking root tarballs need to take care to pass
> >    --xattrs-include=* to tar.

> The tar documentation suggests that just --xattrs should be enough:

>   By default, when '--xattr' is used, all names are stored in the
>   archive (or extracted, if using '--extract').

> Am I missing something?

Empirically derived, on bionic:

# mkdir /tmp/caps
# cd /tmp/caps/
# tar -c --xattrs /usr/bin/mtr-packet | tar -x
tar: Removing leading `/' from member names
# getcap usr/bin/mtr-packet
# tar -c --xattrs /usr/bin/mtr-packet | tar -x --xattrs
tar: Removing leading `/' from member names
# getcap usr/bin/mtr-packet
# tar -c --xattrs /usr/bin/mtr-packet | tar -x --xattrs-include=*
tar: Removing leading `/' from member names
# getcap usr/bin/mtr-packet
usr/bin/mtr-packet = cap_net_raw+ep
#

Same behavior on xenial.

So while the documentation may say it's not required, and we could fix the
implementation going forward to match the documentation (including in SRU in
Ubuntu), if this is an upstream bug this would still be an issue with
implementations in the wild.

--
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/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Kees Cook-5
In reply to this post by Steve Langasek-6
On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:
>  - Where root filesystems are distributed as tarballs, they are not
>    currently created with --xattrs; this will need to be changed.

What about initramfs? CPIO doesn't support xattr:
https://lkml.kernel.org/r/1516850875-25066-1-git-send-email-takondra@...

>  - 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).

How about making these default-enabled? Hoping people will remember seems
fragile.

>  - GNU tar's xattrs format incompatible with other unpack implementations
>    (e.g. libarchive)[1].  Anyone using another unpacker will necessarily
>    end up without fscaps.

Seems like these unpackers should be fixed?

-Kees

--
Kees Cook

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Steve Langasek-6
On Thu, Aug 02, 2018 at 09:41:11AM -0700, Kees Cook wrote:
> On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:
> >  - Where root filesystems are distributed as tarballs, they are not
> >    currently created with --xattrs; this will need to be changed.

> What about initramfs? CPIO doesn't support xattr:
> https://lkml.kernel.org/r/1516850875-25066-1-git-send-email-takondra@...

This seems like it would only be relevant for IMA, not for fscaps (since
everything in the initramfs runs as uid 0).  Is that fair to say?

Since lack of xattrs in cpio is a known limitation, and files don't end up
in an initrd without specific action by a package (which would be the same
in Debian and Ubuntu), I think this is severable from the question of
requiring xattr-preserving handling of an Ubuntu root filesystem.

> >  - 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).

> How about making these default-enabled? Hoping people will remember seems
> fragile.

I think that's appropriate to pursue with the upstream, but that we should
still socialize the recommendation to use the options explicitly for
portability.

> >  - GNU tar's xattrs format incompatible with other unpack implementations
> >    (e.g. libarchive)[1].  Anyone using another unpacker will necessarily
> >    end up without fscaps.

> Seems like these unpackers should be fixed?

Actually it looks like this might have already been done.
https://github.com/libarchive/libarchive/pull/691

However, this code has only landed in libarchive 3.3.0; Ubuntu 18.04 has
libarchive 3.2.2 (as does cosmic).  I would consider a cherry-pick of this
appropriate for an SRU, if some Ubuntu developer thought it important enough
to do the work.

--
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/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Kees Cook-5
On Thu, Aug 02, 2018 at 11:21:28AM -0700, Steve Langasek wrote:

> On Thu, Aug 02, 2018 at 09:41:11AM -0700, Kees Cook wrote:
> > On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:
> > >  - Where root filesystems are distributed as tarballs, they are not
> > >    currently created with --xattrs; this will need to be changed.
>
> > What about initramfs? CPIO doesn't support xattr:
> > https://lkml.kernel.org/r/1516850875-25066-1-git-send-email-takondra@...
>
> This seems like it would only be relevant for IMA, not for fscaps (since
> everything in the initramfs runs as uid 0).  Is that fair to say?

Okay, that's true -- I can't think of anything that expects to run without
privileges during initramfs.

> Since lack of xattrs in cpio is a known limitation, and files don't end up
> in an initrd without specific action by a package (which would be the same
> in Debian and Ubuntu), I think this is severable from the question of
> requiring xattr-preserving handling of an Ubuntu root filesystem.

Agreed.

> > >  - 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).
>
> > How about making these default-enabled? Hoping people will remember seems
> > fragile.
>
> I think that's appropriate to pursue with the upstream, but that we should
> still socialize the recommendation to use the options explicitly for
> portability.

While I agree about pursuing it with upstreams, I don't agree about just
leaving this to documentation/luck. The problem is distro-specific (i.e.
the packages built and the root filesystem being used), so I think it's
fair to make the tools involved in that distro DTRT by default when it
comes to xattrs. (Everything else is expected to work together correctly,
why not the tools too?)

-Kees

--
Kees Cook

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Dimitri John Ledkov
In reply to this post by Steve Langasek-6
On 2 August 2018 at 01:58, Steve Langasek <[hidden email]> wrote:

> 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.
>

For the cases when one forgets to unpack with extended attributes, the
packages in question imho should ship a tmpfiles.d snippet such that
these extended attributes are restored on boot (if that given
filesystem is ever booted).

Example:
t /run/cups - - - - security.SMACK64=printing user.attr-with-spaces="foo bar"

For more details see
http://manpages.ubuntu.com/manpages/bionic/en/man5/tmpfiles.d.5.html

It would be even useful imho to add a lintian check for this.

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Colin Watson
In reply to this post by Steve Langasek-6
On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:
> This will require bugfixes in various places, but ideally on a one-time
> basis only.  The primary areas of concern are:

I think launchpad-buildd needs a couple of fixes for this, but there are
some things to fix that aren't quite one-liners.

Firstly, we need to pass --xattrs-include=* when unpacking chroots.
That much is straightforward.

Secondly, the machinery that creates Launchpad build chroots needs to
pass --xattrs.  That machinery is currently Adam Conrad's shell history,
but we're in the process of moving it into livecd-rootfs, and that will
need a minor adjustment.

The third problem is the one that isn't trivial.  Some Launchpad builds
are run in LXD containers rather than in chroots, and in those cases we
first mangle the chroot tarball into a shape that can be imported by
LXD.  We currently do this using Python 2.7's tarfile module, but as far
as I can see that doesn't quite support xattrs properly due to encoding
issues.  I can think of a couple of options:

 * We could take some approach like
   https://github.com/docker/docker-registry/pull/381/files to
   monkey-patch tarfile, or we could finish the upgrade of
   launchpad-buildd to Python 3 (which is within reach).  In either
   case, we'd need to work out how to invoke tarfile correctly to
   preserve xattrs; I think that's probably a fairly small change, but
   it'll require some investigation and testing.

 * Once we've completed the move of chroot creation into livecd-rootfs,
   it may be practical to have that produce LXD containers too, and in
   that case we could drop the Python-based mangling.  In the long term
   this would be preferable because it would save a minute or two at the
   start of many builds.

None of this is super-urgent since I don't think there's anything in the
chroots that requires xattrs, but we should remember to fix it to avoid
future surprises.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Steve Langasek-6
In reply to this post by Kees Cook-5
On Thu, Aug 02, 2018 at 01:29:26PM -0700, Kees Cook wrote:
> > > >  - 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).

> > > How about making these default-enabled? Hoping people will remember seems
> > > fragile.

> > I think that's appropriate to pursue with the upstream, but that we should
> > still socialize the recommendation to use the options explicitly for
> > portability.

> While I agree about pursuing it with upstreams, I don't agree about just
> leaving this to documentation/luck. The problem is distro-specific (i.e.
> the packages built and the root filesystem being used), so I think it's
> fair to make the tools involved in that distro DTRT by default when it
> comes to xattrs. (Everything else is expected to work together correctly,
> why not the tools too?)

I don't think this is an either-or proposition.  I think we need to document
it because existing tooling doesn't DTRT by default, and I think we need to
work with upstream to get the defaults changed (upstream, because we can't
assume that our users are using Ubuntu's tar binary when unpacking Ubuntu
root tarballs).

I've filed two bugs in launchpad for this on the respective packages.

  https://bugs.launchpad.net/ubuntu/+source/tar/+bug/1785291
  https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1785302

--
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/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Tom H-4
In reply to this post by Steve Langasek-6
On Thu, Aug 2, 2018 at 4:10 PM Steve Langasek <[hidden email]> wrote:
>
> # tar -c --xattrs /usr/bin/mtr-packet | tar -x --xattrs-include=*

FYI, the Gentoo handbook recommends '--xattrs-include="*.*"' for
unpacking its tarball.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Stéphane Graber-2
In reply to this post by Steve Langasek-6
On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:

> 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].
We've taken care of this part now:
 - https://github.com/lxc/lxd/pull/4861
 - https://github.com/lxc/lxd/pull/4868
 - https://github.com/lxc/lxd/pull/4870
 - https://github.com/lxc/lxd/pull/4875

Note that this requires a 4.14 or higher kernel to work as it requires
support for unprivileged file capabilities.

For Ubuntu specifically, this particular patchset (written by Serge
Hallyn) is getting backported to our 4.4 kernel, but that won't be true
for other distributions.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1778286

>
> 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/
> [hidden email]                                     [hidden email]
>
> [1] https://github.com/opencontainers/image-spec/issues/725
> [2] https://github.com/lxc/lxd/issues/4862


> --
> ubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Stéphane Graber-2
On Sun, Aug 05, 2018 at 11:18:49AM -0400, Stéphane Graber wrote:

> On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:
> > 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].
>
> We've taken care of this part now:
>  - https://github.com/lxc/lxd/pull/4861
>  - https://github.com/lxc/lxd/pull/4868
>  - https://github.com/lxc/lxd/pull/4870
>  - https://github.com/lxc/lxd/pull/4875
>
> Note that this requires a 4.14 or higher kernel to work as it requires
> support for unprivileged file capabilities.
>
> For Ubuntu specifically, this particular patchset (written by Serge
> Hallyn) is getting backported to our 4.4 kernel, but that won't be true
> for other distributions.
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1778286
And just noticed that we have another problem on Xenial as our
squashfs-tools there has broken xattr support in unsquashfs.

I filed a bug and will follow-up with a SRU shortly:

https://bugs.launchpad.net/ubuntu/+source/squashfs-tools/+bug/1785499


> > 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/
> > [hidden email]                                     [hidden email]
> >
> > [1] https://github.com/opencontainers/image-spec/issues/725
> > [2] https://github.com/lxc/lxd/issues/4862
>
>
>
> > --
> > ubuntu-devel mailing list
> > [hidden email]
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com


--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Robie Basak-4
In reply to this post by Steve Langasek-6
On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:
> This will require bugfixes in various places, but ideally on a one-time
> basis only.  The primary areas of concern are:

[...]

>  - Users who are unpacking root tarballs need to take care to pass
>    --xattrs-include=* to tar.

I think it's worth pointing out that users unpacking root tarballs to
filesystems that don't support xattrs will be broken. I'm not sure how
widespread this is, but I'm thinking of the use of cloud images and the
Ubuntu Base image. In the interests of moving forward, perhaps it makes
sense to make this breaking change in Ubuntu.

Would it be an idea to make it such that booting an Ubuntu system on a
filesystem that doesn't support xattrs deliberately fails early, to
avoid users being hit with subtle bugs later? The error could include
instructions on disabling the check for users who want to proceed
anyway.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Steve Langasek-6
On Mon, Aug 06, 2018 at 02:23:30PM +0100, Robie Basak wrote:
> On Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote:
> > This will require bugfixes in various places, but ideally on a one-time
> > basis only.  The primary areas of concern are:

> [...]

> >  - Users who are unpacking root tarballs need to take care to pass
> >    --xattrs-include=* to tar.

> I think it's worth pointing out that users unpacking root tarballs to
> filesystems that don't support xattrs will be broken. I'm not sure how
> widespread this is, but I'm thinking of the use of cloud images and the
> Ubuntu Base image. In the interests of moving forward, perhaps it makes
> sense to make this breaking change in Ubuntu.

I think it's exceedingly unlikely that anyone is going to unpack, and
subsequently boot, an Ubuntu root tarball on a filesystem that doesn't
support xattrs.  All the filesystems that Ubuntu supports out of the box as
rootfs (in terms of installers, and filesystem tools preinstalled) support
xattrs.

> Would it be an idea to make it such that booting an Ubuntu system on a
> filesystem that doesn't support xattrs deliberately fails early, to
> avoid users being hit with subtle bugs later? The error could include
> instructions on disabling the check for users who want to proceed
> anyway.

IMHO that would be overengineering for a corner case.

--
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/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

John Lenton-2
On Mon, 6 Aug 2018 at 21:16, Steve Langasek <[hidden email]> wrote:
>
> I think it's exceedingly unlikely that anyone is going to unpack, and
> subsequently boot, an Ubuntu root tarball on a filesystem that doesn't
> support xattrs.  All the filesystems that Ubuntu supports out of the box as
> rootfs (in terms of installers, and filesystem tools preinstalled) support
> xattrs.

while this is strictly true, 'snap pack' and 'snapcraft pack'
currently disable xattrs, and the store will not approve snaps that
are built with xattrs.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Steve Langasek-6
Hi John,

On Mon, Aug 06, 2018 at 10:09:53PM +0100, John Lenton wrote:
> On Mon, 6 Aug 2018 at 21:16, Steve Langasek <[hidden email]> wrote:

> > I think it's exceedingly unlikely that anyone is going to unpack, and
> > subsequently boot, an Ubuntu root tarball on a filesystem that doesn't
> > support xattrs.  All the filesystems that Ubuntu supports out of the box as
> > rootfs (in terms of installers, and filesystem tools preinstalled) support
> > xattrs.

> while this is strictly true, 'snap pack' and 'snapcraft pack'
> currently disable xattrs, and the store will not approve snaps that
> are built with xattrs.

Thanks, that's a useful data point.  Do you think it is a practical concern
for snaps if an Ubuntu rootfs uses fscaps?  Is this an argument against
allowing fscaps in Ubuntu, or should it just be a matter for snapcraft to
warn/error about on creation, guiding users to using setuid instead?

As a worked example: the core snap does ship /bin/ping, which is currently
setuid-root in Ubuntu but would move to fscaps in this proposal.  (The core
snap does not include mtr-tiny.)  What do you believe is the correct outcome
here for /bin/ping in a future ubuntu core 20 snap?

--
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/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

John Lenton-2
On Mon, 6 Aug 2018 at 22:53, Steve Langasek <[hidden email]> wrote:

>
> Thanks, that's a useful data point.  Do you think it is a practical concern
> for snaps if an Ubuntu rootfs uses fscaps?  Is this an argument against
> allowing fscaps in Ubuntu, or should it just be a matter for snapcraft to
> warn/error about on creation, guiding users to using setuid instead?
>
> As a worked example: the core snap does ship /bin/ping, which is currently
> setuid-root in Ubuntu but would move to fscaps in this proposal.  (The core
> snap does not include mtr-tiny.)  What do you believe is the correct outcome
> here for /bin/ping in a future ubuntu core 20 snap?

Given that fine-grained fscaps are better than blanket setuids, I
expect core 20 to embrace them wholeheartedly.
However, getting there will involve the whole
snapcraft/snapd/review-tools/snapstore stacks for at least a little
bit of work.

We need to sit down and decide what shape that support is going to
take (basically: can everybody have xattrs & fscaps, or is it just
base snaps? any base snap, or only core? policy decisions, involving
security). I don't expect it to be controversial, unless we want to
enable a snapped application to use fscaps.

We need to do a bit of research _today_, because already 16.04 has
tools that rely on fscaps: this conversation has had me notice that
systemd-detect-virt, that we ship in core and use from snapd in a
couple of places (and in particular to check whether we need to use
squashfuse) is using caps instead of setuid, meaning that in core for
a regular user it probably won't work properly. So we'll need to look
into exactly how it's being used; I _think_ we're testing them as
root, and only expect to be using them as root, but we'll have to
chase it down.

We need to make sure the races that plagued us around execing setuids
aren't revived by fscaps.  They shouldn't.

I think that's all.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Jamie Strandboge-3
In reply to this post by Steve Langasek-6
On Mon, 2018-08-06 at 14:53 -0700, Steve Langasek wrote:

> Hi John,
>
> On Mon, Aug 06, 2018 at 10:09:53PM +0100, John Lenton wrote:
> > On Mon, 6 Aug 2018 at 21:16, Steve Langasek <steve.langasek@ubuntu.
> > com> wrote:
> > > I think it's exceedingly unlikely that anyone is going to unpack,
> > > and
> > > subsequently boot, an Ubuntu root tarball on a filesystem that
> > > doesn't
> > > support xattrs.  All the filesystems that Ubuntu supports out of
> > > the box as
> > > rootfs (in terms of installers, and filesystem tools
> > > preinstalled) support
> > > xattrs.
> > while this is strictly true, 'snap pack' and 'snapcraft pack'
> > currently disable xattrs, and the store will not approve snaps that
> > are built with xattrs.
>
> Thanks, that's a useful data point.  Do you think it is a practical
> concern
> for snaps if an Ubuntu rootfs uses fscaps?  Is this an argument
> against
> allowing fscaps in Ubuntu, or should it just be a matter for
> snapcraft to
> warn/error about on creation, guiding users to using setuid instead?
>
> As a worked example: the core snap does ship /bin/ping, which is
> currently
> setuid-root in Ubuntu but would move to fscaps in this
> proposal.  (The core
> snap does not include mtr-tiny.)  What do you believe is the correct
> outcome
> here for /bin/ping in a future ubuntu core 20 snap?
App snaps are currently expected to be generated with --no-xattrs and I
continue to believe this is the correct choice for the time being.

os/base snaps need not be expected to be built this way and we while
might have some light review tools updates for this, in principle it is
not a problem for os/base snaps.

--
Jamie Strandboge             | http://www.canonical.com
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Neal Gompa
In reply to this post by Steve Langasek-6
On Mon, Aug 6, 2018 at 5:53 PM Steve Langasek <[hidden email]> wrote:

>
> Hi John,
>
> On Mon, Aug 06, 2018 at 10:09:53PM +0100, John Lenton wrote:
> > On Mon, 6 Aug 2018 at 21:16, Steve Langasek <[hidden email]> wrote:
>
> > > I think it's exceedingly unlikely that anyone is going to unpack, and
> > > subsequently boot, an Ubuntu root tarball on a filesystem that doesn't
> > > support xattrs.  All the filesystems that Ubuntu supports out of the box as
> > > rootfs (in terms of installers, and filesystem tools preinstalled) support
> > > xattrs.
>
> > while this is strictly true, 'snap pack' and 'snapcraft pack'
> > currently disable xattrs, and the store will not approve snaps that
> > are built with xattrs.
>
> Thanks, that's a useful data point.  Do you think it is a practical concern
> for snaps if an Ubuntu rootfs uses fscaps?  Is this an argument against
> allowing fscaps in Ubuntu, or should it just be a matter for snapcraft to
> warn/error about on creation, guiding users to using setuid instead?
>
> As a worked example: the core snap does ship /bin/ping, which is currently
> setuid-root in Ubuntu but would move to fscaps in this proposal.  (The core
> snap does not include mtr-tiny.)  What do you believe is the correct outcome
> here for /bin/ping in a future ubuntu core 20 snap?
>

The upcoming Fedora base snap is likely to require maintaining xattrs,
since we heavily use fscaps, among many other things. So this
requirement will likely change.



--
真実はいつも一つ!/ Always, there's only one truth!

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps

Jamie Strandboge-3
In reply to this post by John Lenton-2
On Mon, 2018-08-06 at 23:23 +0100, John Lenton wrote:

> On Mon, 6 Aug 2018 at 22:53, Steve Langasek <[hidden email]
> m> wrote:
> >
> > Thanks, that's a useful data point.  Do you think it is a practical
> > concern
> > for snaps if an Ubuntu rootfs uses fscaps?  Is this an argument
> > against
> > allowing fscaps in Ubuntu, or should it just be a matter for
> > snapcraft to
> > warn/error about on creation, guiding users to using setuid
> > instead?
> >
> > As a worked example: the core snap does ship /bin/ping, which is
> > currently
> > setuid-root in Ubuntu but would move to fscaps in this
> > proposal.  (The core
> > snap does not include mtr-tiny.)  What do you believe is the
> > correct outcome
> > here for /bin/ping in a future ubuntu core 20 snap?
>
> Given that fine-grained fscaps are better than blanket setuids, I
> expect core 20 to embrace them wholeheartedly.
> However, getting there will involve the whole
> snapcraft/snapd/review-tools/snapstore stacks for at least a little
> bit of work.
>
> We need to sit down and decide what shape that support is going to
> take (basically: can everybody have xattrs & fscaps, or is it just
> base snaps? any base snap, or only core? policy decisions, involving
> security). I don't expect it to be controversial, unless we want to
> enable a snapped application to use fscaps.
>
FYI, I don't think we should blindly allow fscaps for 'app' snaps since
this is a huge can of worms. *But* we can and in fact already do allow
fscaps (and setuid, setgid, non-root uids, etc, etc) in the privileged
base and os snaps.

> We need to do a bit of research _today_, because already 16.04 has
> tools that rely on fscaps: this conversation has had me notice that
> systemd-detect-virt, that we ship in core and use from snapd in a
> couple of places (and in particular to check whether we need to use
> squashfuse) is using caps instead of setuid, meaning that in core for
> a regular user it probably won't work properly. So we'll need to look
> into exactly how it's being used; I _think_ we're testing them as
> root, and only expect to be using them as root, but we'll have to
> chase it down.

I suspect if you built the core snap without -no-xattrs, it would work.
It might not, but IMO that would be a bug (I certainly would expect
them to in os and base snaps).

--
Jamie Strandboge             | http://www.canonical.com
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment