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.
Cheers,
--
intrigeri
