On 08/04/2017 12:05 PM, John Johansen wrote: << snip >>
>> >> I am not aware of any plans for Flatpak to rely on an LSM: it's all >> done with namespaces, seccomp and NO_NEW_PRIVS. Flatpak is entirely >> unprivileged, and bubblewrap doesn't retain CAP_MAC_ADMIN (it's setuid >> on Debian and RHEL, but is designed to be unnecessary to make setuid on >> distributions like Fedora and Ubuntu that allow unprivileged userns >> creation). >> >>> 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. >> > it is possible, but there are currently issues To clarify, the issues revolve around mount namespaces, and no_new_privs. no_new_privs due to a discussion by the kernel developers to limit the lsm when it is applied. For most uses this isn't a problem, apparmor confinement can be applied just fine. However it does apparmor from transitioning policy when no-new-privs is applied. Basically no-new-privs can cause restrictions on apparmor policy. The mount namespace issue, is covered some below. > >> 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!) >> > This is a real problem currently. We are working on fixing it, but its > not just an apparmor issue. On the apparmor end of things, apparmor > now supports policy namespaces and stacking, allowing for policy > within a container to expect and be fine with a different root. The > delegation and inode labeling support are still a wip and will > provide another avenue for dealing with some of the issues. > The policy namespaces work well for policy inside a container situations, eg. having an lxd container load its own system policy and have it apply, separate from the host system policy. They do not currently fix the cross mount namespace issues that Simmon brought up. Where the system policy is authored from the pov of a different mount namespace. If you are interested in the fixes for these, we can poke at the solutions more but I don't think they will help this discussion beyond saying fixes for the issues are coming at some point in the future. I am not willing to commit to a time frame atm as we are trying hard to take an upstream first approach that will benefit everyone. > However there The kernel currently doesn't make it possible at the > LSM level to properly manage namespaces. > > There is a micro-conference at plumbers and bof at LSS this year to > work on the problems of namespacing and the LSM. Hopefully we can > fix these issues soon. > -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
