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