[apparmor] RFC: draft proposal for enabling AppArmor by default in Debian

[intrigeri]

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