Re: Let's enable AppArmor by default (why not?)
- Date: Wed, 09 Aug 2017 17:31:18 -0400
- From: intrigeri <intrigeri@xxxxxxxxxx>
- Subject: Re: Let's enable AppArmor by default (why not?)
[John, there's a question for you at the bottom, but you probably have
useful input about the first part of the discussion below too.]
> Christian Seiler <christian@xxxxxxxx> schrieb:
>> Another thing to consider: if a profile is too restrictive, but the
>> part that is too restrictive isn't in the upstream kernel yet, then
>> things could break if you upgrade the kernel to a newer version from
>> e.g. backports later on. How would you deal with that kind of
>> breakage during the lifetime of a stable release?
> Agreed, that was pretty much my concern.
Thank you so much for highlighting problems I had missed! :)
A simple, but not entirely satisfying answer is:
1. Gather info about how real this problem has been in practice for
Ubuntu: they frequently update their kernel for various already
released distros with the latest AppArmor bits. I think they
occasionally have to update other packages accordingly to adjust
AppArmor policy. I don't know how often this happens. I'll ask them
to compile a list of such stable updates.
2. Evaluate for a year how it goes for Stretch + Linux from backports.
Desktop: I'm in a good place to provide data points, as Tails
generally ships this combination and we exercise the vast majority
of the desktop AppArmor stuff that's in Debian.
Server: sorry, I use the stable kernel except on bare-metal
virtualization hosts. But I think (1) will give us enough data on
3. Depending on what (1) and (2) tell us, decide whether "we might
have to update AppArmor policy from time to time in stable
point-releases or backports" is good enough… keeping in mind that
other distros are already dealing with the exact same problem, so
we won't have to do this alone. And if it's not good enough:
> Ideally the feature set used would also be controlled by the
> apparmor userspace side.
If we need to go this far: apparmor_parser has a --features-file
option that we could leverage to tie the feature set being used to
something else than the version of the running kernel, e.g.
with a file shipped in a new package built from src:linux with
appropriate versioned dependencies.
> Also, I'm wondering about the status of kernel support which is
> currently not upstreamed: intrigeri mention that new features are
> now added to Linux mainline. Was there ever an attempt to upstream
> those existing patches (e.g. for network socket mediation); was it
> NACKed by upstream for conceptual problems or was it simply never
> attempted due to time/resource constraints?
I'm not sure, so I'll let the main AppArmor kernel developer (John,
Cc'ed) answer this.