Jamie Strandboge: > On Fri, 2017-08-04 at 13:07 +0100, Simon McVittie wrote: >> I am not aware of any plans for Flatpak to rely on an LSM: …[]
> Actually, adding SELinux support was on the flatpak roadmap, at least at one > point. Yeah, this does ring a bell. I must have been confused by 1. the fact that bubblewrap itself has some specific functionality that only works with SELinux; 2. my (possibly faulty) memory of a (possibly buggy) report from a team-mate of mine who came back from GUADEC 2016 stating that there were plans to also support AppArmor in bubblewrap. > I think integeri's comment was directed at the open question in the > larger security community of whether containers (system or user) are > sufficiently strong to be used alone as a sandboxing technology for arbitrary > untrusted binaries. Actually, that wasn't what I meant. I was genuinely under the mistaken belief that most of the leading/upcoming app sandboxing technologies had plans to use a LSM. Thank you both for the clarifications! I'll update the proposal so it's both more correct technically and less misleading. >> > In any case, it is my understanding that this is not an either/or >> > situation: one can perfectly well use this tools with >> > AppArmor enabled. >> >> Mount namespaces interact poorly with a path-based LSM like AppArmor. >> With the way in which Bubblewrap currently uses pivot_root() in its >> private mount namespace, a Flatpak app will currently appear to >> AppArmor to be accessing filenames like /newroot/app/bin/openarena, >> /newroot/usr/lib/libGL.so.1 and /newroot/home/smcv/, and it does not >> appear to be possible to disambiguate which root we are operating in. >> >> (I would love to be proved wrong on this!) > Actually, with sufficient invocations of pivot_root, you don't need to specify > '/newroot' and simply have rules for '/app/bin/...', '/usr/lib/...' and > '/home/...' (unlike chroot). We do this in snappy today for example. Using > those > techniques, you are right you can't disambiguate /newroot1 vs /newroot2 in > policy, but if that is important, you can code the sandboxing application for > that in mind. Sounds like good news to my ear :) Looks like someone should help Flatpak people do it in a way that's more AppArmor-friendly. I'm sorry I lack the skills to do this myself :( Cheers, -- intrigeri -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
