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. _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
