Re: Playing around with ostree for apps

[Alexander Larsson <alexl redhat com>]

On tis, 2014-10-14 at 18:14 -0400, Colin Walters wrote:
> > I agree, we don't want to have setuid binaries lying around, even in the
> > repo. Can we have files in the repo not store the setuid bit? That would
> > mean we have to copy the file (not hardlink) when checking out, but how
> > many files are setuid? Then we could have a no-setuid checkout mode
> > similar to -U that does not apply this flag at all.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=722984
>
> But this seems like a case for "ostree pull --untrusted" or so?
>
> Even this though I'm not sure about because it seems likely to me that
> we want SELinux labeling to happen at install time, by the host policy,
> or conversely that apps shouldn't get to determine labels.  Possibly we
> could enforce that the apps come without security.selinux, but then to
> ensure sharing we'd have to compute the checksum on the client of
> content + label.
>
> Going to have the same SELinux issues with apps-as-btrfs too of course.

Actually, when it comes to selinux you generally don't want the selinux
labeling on the files. Instead you want the selinux context to come from
the global mount inside the app filesystem namespace (in general you
want a system-unique selinux context for each running app instance, to
protect e.g. two instances of the same app from each other).
Unfortunately this is not currently doable unless the mount has an
unique superblock, which a bind mount doesn't have...

We have similar issues with selinux and docker actually. For the docker
devmapper backend we're using a single unique COW dm device for each
container, so we can mount that with a selinux context and everything is
fine. This doesn't work for the btrfs and overlayfs backends though. For
the btrfs backend we're looking at changing btrfs itself to allow
subvolume mount contexts, but that wouldn't neccessarily work for us
anyway, as we're not using a unique subvolume per running app instance.

I don't really know how to handle this at all. The best approach would
be if we could hang the unique selinux context off the bind mount in the
app filesystem namespace, but that is not possible atm.