[pkg-lxc-devel] Bug#916639: LXC AppArmor confinement breaks systemd v240

[Pierre-Elliott Bécue]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-lxc-devel/attachments/20190210/ab855db0/attachment.sig>