Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Wed, Jun 12, 2019 at 11:40:57AM -0700, Brian Murray wrote: > For the record, I've found out[1] this is actually an upstream bug in > the documentation for which I have submitted some patches to clarify the > behavior of --xattrs-include. > > [1] https://lists.gnu.org/archive/html/bug-tar/2019-06/msg2.html Thanks for chasing this up! -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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? For the record, I've found out[1] this is actually an upstream bug in the documentation for which I have submitted some patches to clarify the behavior of --xattrs-include. [1] https://lists.gnu.org/archive/html/bug-tar/2019-06/msg2.html -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Mon, Aug 6, 2018 at 5:53 PM 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 > > 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Mon, 6 Aug 2018 at 21:16, Steve Langasek 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Thu, Aug 2, 2018 at 4:10 PM Steve Langasek 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Mon, 6 Aug 2018 at 22:53, Steve Langasek 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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 > 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 signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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/ > > slanga...@ubuntu.com vor...@debian.org > > > > [1] https://github.com/opencontainers/image-spec/issues/725 > > [2] https://github.com/lxc/lxd/issues/4862 > > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > 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 signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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/ > slanga...@ubuntu.com vor...@debian.org > > [1] https://github.com/opencontainers/image-spec/issues/725 > [2] https://github.com/lxc/lxd/issues/4862 > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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 [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On 2 August 2018 at 01:58, 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. > 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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-takon...@cisco.com > > 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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-takon...@cisco.com 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
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 [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
