Re: Dilemma using ostree as regular user, losing permission bits

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Tue, 2017-06-06 at 16:02 +0900, Tristan Van Berkom wrote:
[...]

Actually let me follow up on this because this really gets to the root
of the issue I think:

> > The rationale for clearing suid bits is that you *really* don't want to
> > create suid binaries owned by your build user - any
> > other user on the system could execute them to gain *your* uid's
> > privileges.
> >
> > Another way to say this is that bare-user is designed for *container*
> > use cases, and builds should always be in a container that runs
> > as non-root.  And IMO, you shouldn't use suid binaries in containers.
> > There's absolutely no use case for having e.g. a suid `/usr/bin/sudo`
> > in your build containers.  Nor for any of the PAM binaries, etc.

So yes, having a setuid 'sudo' belonging to you, means that any other
user on your machine could potentially gain your privileges through it;
creating a setuid 'sudo' in your home account somewhere is certainly
not recommendable.

On the other hand, if you want to create a bootable image as a regular
user, and you want that image to contain a /usr/bin/sudo that is
setuid, the typical way to do that is:

  1.) Create a sysroot somehow

  2.) Run mkfs.ext4 filesys.img -d ${sysroot}

Now it is conceivable to have userspace utilities to modify permissions
of files inside an image without mounting it, so we could set the suid
bit on 'sudo' inside filesys.img, but:

  a.) These tools are quite limited, I think you might have something
      for this in genext2fs, not sure you can do it for btrfs.

      The guestfish project shows promise, but is immensely complicated
      to build and then run inside a bubblewrap sandbox (requires qemu,
      and needs some custom supporting code to define an "appliance").

      This is especially tricky because we are striving for fully
      deterministic builds, which means any such tooling should be
      made available to the sandbox, usually by building it, there
      should never be a host tool dependency for deployments.

  b.) It would be convoluted, the authors of build metadata would have
      to express this separately and the suid-ness of things would have
      to be carried beside the filesystem data itself separately.

      Seems to me much more straight forward to ensure suid of
      /usr/bin/sudo after 'make DESTDIR=foo install' time once and
      trust that it will be there again when you checkout the tree
      and try to assemble the image.

I admit it's an interesting conundrum; am I willing to own an suid
binary as a regular user for the sake of creating something that needs
to have an suid binary in it somehow ?

I think so, practically speaking multi user linux systems are not
immensely common, perhaps this raises more issues in the case that your
build server is also hosting a malicious cgi script, allowing it
(through apache) to gain privileges of your builder user ?

Best Regards,
    -Tristan