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 <christ...@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.