Re: Let's enable AppArmor by default (why not?)
On 08/09/2017 02:31 PM, intrigeri wrote:
> Hi,
>
> [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.]
>
> Moritz Mühlenhoff:
>> Christian Seiler <christian@iwakd.de> 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
> this front.
>
> 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:
>
There are several distinct issues when dealing with stable release
support. There are basically 3 different potentially moving components
to consider
kernel - changes may result in a change in the supported feature
set.
policy - a package may backport/drop in policy that was developed on
a different feature set.
user space - changes/updates may be required to support new features
in a kernel or policy.
The question specifically asks about, an updated kernel with a policy
that was developed under a different feature set, suddenly breaking
when a new kernel is run on an older system.
The kernel portion is designed to support multiple versions of
userspace policy abis, and while we have dropped some of the older
abis, it is done slowly. The current kernel code supports the abi from
2009. So newer kernels will support older policy and userspaces.
Similarly the userspace is designed to support multiple kernel
versions and abis, so a newer userspace (if it is SRUed for some
reason) can support older kernels.
This leaves us dealing with policy. As long as the policy has not been
changed, it is possible to force userspace to build policy for a
certain kernel feature set by specifying the feature file.
This can be done in the apparmor/subdomain.conf file
with this specified, policy should remain to be compiled as for the
older kernel, and the new kernel should support and enforce it under
that abi.
There is however a caveat that sometimes the kernel changes abi
behavior in ways that apparmor can not adapt to without policy
modification.
An example of this would be
commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46
binfmt_elf: switch to new creds when switching to new mm
which resulted in a change of which cred the PROT_EXEC request was
made against. With the way the lsm hook is designed only the single
cred is available so it is not even possible for apparmor to emulate
the old behavior.
In this case older policy needed to be patched to support the newer
behavior if it was to be used on a newer kernel, and a flag was
added to the apparmor kernel features interface making it possible
for userspace to detect that the kernel contained the change.
Thankfully this type of change is has not been very common.
>> 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.
>
the feature file can indeed be specified on the command line using
--feature-file, but from a support pov I think specifying it in the
config file
apparmor/subdomain.conf
would be better as then you don't have to mess with initscripts, unit
files, etc.
>> 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.
>
So current status of kernel support that hasn't been upstreamed is
4.13 - has most everything. It has the virtualized apparmorfs and
namespacing interfaces, the core rework, stacking, etc. It is
missing some key features, specifically signals, mount and
network mediation
4.14 - isn't fully decided yet, but it should pickup everything except
maybe the extended unix socket mediation
As for why upstreaming has taken so long, there have been several
reasons.
Time constraints have been the major issue. Certain new feature
development was certainly prioritized over getting existing out of
tree features upstream. There is recognition that this was the wrong
approach and there is now an upstream first policy.
In addition some of the delay has also been just a matter of letting
code bake and shaking out bugs. Some of the code has had several
revisions before we were happy with it and thought it ready to be
upstreamed.
Eg. the extension to securityfs to allow apparmor to virtualize its
policy dir has seen several revisions. And even changed approach
before the final version which was upstreamed in 4.13. It just took
some time for the code to bake and for the correct approach to settle
out. Ubuntu was willing to carry the dev code to get certain features
early, at an increased cost in support.
The dbus code went through several revisions as well. While the dbus
code doesn't require a lot from the kernel, it did have some influence
on the kernel support interfaces.
Another reason many of these features were delayed in their
upstreaming, is the apparmor core was being rewritten during their
development, which unfortunately resulted in there not being a clean
separation between the different parts of development. So while some
features could have been upstreamed sooner they had to wait for the
core changes to bake, or be rewritten to work with the existing
upstream code (time and resources weren't available for the rewrite).
None of the current development has been NAKed upstream. At times in
the past certain approaches have been NAKed, and required reworking.
This was largely around how apparmor interacted with the system and
modifications to the LSM hooks. That is not to say that some of the
existing out of tree features might not get naked or need some
reworking before they land upstream.
We have been trying to drive the diff down to 0, and we are now close.
Reply to: