Le dimanche 27 janvier 2019 à 19:47:59+0100, intrigeri a écrit : > Hi, > > Pierre-Elliott Bécue: > > We have to decide what solution I will implement. > > Right, thanks for following up. > > > I'm open to suggestions, although I'm considering the "disable > > apparmor profiles for lxc" solution for now. > > I think that disabling AppArmor by default for new LXC containers for > Buster would be an OK-ish fallback option, if nothing else can > realistically be made to work in time for the freeze; that would be > sad, but it would not be a regression vs. Stretch. I assume we are on > the same page regarding this: by all means, let's not ship a known > broken LXC + AppArmor default configuration in Buster :) > > Apart of this fallback, I can propose two options: > > A) Add a blanket "mount," rule to the base AppArmor policy used by all > profiles used for individual containers. > > Pros: I guess that it's the cheapest possible way to have *some* > working AppArmor policy enabled by default. > > Cons: > > - This diverges from upstream quite a bit, and more importantly, > in a non-obvious way, so users coming from other distros may be > assuming a stricter default policy. > > - It's non-trivial for users to opt in for a stricter > AppArmor policy. > > B) Apply the patches I've backported and proposed, > and make these settings the default: > > lxc.apparmor.profile = generated > lxc.apparmor.allow_nesting = 1 > > … which effectively adds the same blanket "mount," rule > by default. > > Pros: > > - The user has more flexibility wrt. how strictly they want this > or that container to be confined by AppArmor. > > - Nicer UX: most users of LXC in Debian will be exposed to LXC > being confined with AppArmor for the first time in Buster. > It's nicer to give them means to configure it that are here to > stay, i.e. that are the future of the LXC/LXD ecosystem, > compared letting them learn the LXC 3.0.x way only to have to > learn again once they upgrade to a newer LXC or to Bullseye. > > - Easier to document: it's easier to explain what the default > value of these settings is on Debian, than to explain "we added > a blanket 'mount' rule" to users who are not familiar > with AppArmor. > > Cons: > > - Bigger delta vs. upstream 3.0.x branch. I realize this has > a maintenance cost and I guess that's why the maintainers have > not applied the proposed patches yet. > > - This new code has been tested very minimally on LXC 3.0.x. > It works well enough to make the systemd autopkgtests pass, it > comes from LXD, it's has been in upstream's 3.1 branch for > 6 months, but still: there's a certain amount of > uncertainty here. > > Either way, we don't enable mount mediation at all by default, because > as Wolfgang wrote, "the policy changes won't be enough for long". > So the resulting AppArmor policy is quite weak, but as long as users' > expectations are set adequately, it's definitely not worse than what > we have in Stretch nor than the fallback option. > > Personally, I'm leaning towards option (B), which is why I bothered > backporting the patches mid-December, after upstream suggested this > was the way to go. But time has flown since then, and I would > understand if the maintainers don't feel comfortable with this option > so close to the freeze. I can live with option (A) too, and worst > case, well, with the fallback option if that's how it is.
Hey, I feel comfortable with B, but as far as I understood, there was some code needing to be backported not in your patches. Do you think we could take care of it or should I just include your patches as it? -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them.
signature.asc
Description: PGP signature