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 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
Re: Let's enable AppArmor by default (why not?)
On 08/10/2017 11:31 AM, Simon McVittie wrote: > On Wed, 09 Aug 2017 at 17:17:17 -0700, John Johansen wrote: >> 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. > > I'm curious: is the kernel side of D-Bus mediation specific to D-Bus, > or is it general-purpose support for mediating user-space activities > that look roughly the same shape as D-Bus? > The kernel side of D-Bus is generic except one flag. It provides - label/context info to the proc//attr/current and SO_PEER_SEC which are wrapped by the libapparmor api fns - the query interface which allows user space to query policy that is loaded into the kernel. The dbus code was the first consumer so it helped shape what the interface looks like and how the queries are constructed. - a flag in the features advertising that dbus mediation support is available. This last one currently is set by the kernel but ideally would be enabled by the dbus code advising the kernel module it is mediating. For dbus mediation we assigned dbus its own class with in the policydb. Queries to the dbus class need have the dbus query structure, queries to other classes must follow those classes. There is certainly some similarity between the classes, but some of them are quite different from dbus.
Re: Let's enable AppArmor by default (why not?)
On 08/10/2017 02:23 PM, Simon McVittie wrote: > On Thu, 10 Aug 2017 at 12:00:15 -0700, John Johansen wrote: >> but ideally would be enabled by the dbus code advising the >> kernel module it is mediating > > "The" dbus code? There can be several parallel instances of dbus-daemon, > possibly different versions of the executable, certainly differently > configured, which can result in any combination of them having > AppArmor mediation enabled or disabled. For example a typical GNOME > laptop will have a system bus, a session bus for the system user > that runs the gdm greeter, and a session bus for the logged-in user > account. > > It is meaningful to ask whether a specific dbus-daemon instance is > applying AppArmor mediation, and the latest development branches > advertise this by putting "apparmor" in the bus driver's Features > property. In general it isn't necessarily meaningful to say > "the dbus-daemons running on this kernel are applying AppArmor > mediation" because some of them might be an executable that doesn't > support it, and some of them might support it but have it disabled > in configuration. > > So I think this is something that should be queried by asking each > dbus-daemon whether it is mediating, rather than by asking the kernel. > yep having a way to detect/ask individual deamons is the way to go. I was merely commenting on that the current kernel flag not being reflective of actual mediation. Which the dbus daemon is providing, and it (they) should be what is setting the support status, whether in kernel or by a different means. Regardless we will be keeping the kernel flag for several years to provide backwards compat for newer kernels on earlier releases.
Re: Let's enable AppArmor by default (why not?)
On 09/09/2017 12:49 PM, intrigeri wrote: > Hi John et al, > > John Johansen: >> On 08/09/2017 02:31 PM, intrigeri wrote: >>> Moritz Mühlenhoff: >>>> Christian Seiler 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. > >> [...] >> 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. > > Right. > > Below you elaborate about ABI compatibility between the kernel, > userspace and policy. Thanks, I've learned a lot! > > But even more specifically, the question was about policy updates > mandated to avoid breaking *confined applications* when upgrading to > a kernel that mediates more interfaces than the one in Debian stable. > haha, I had a broader answer dealing with some of this and upon review had decided the question was about a newer kernel on an older release, and it would be best to have concise answers around that :) > Christian Seiler put it clearly (quoted above) but here's a more > practical example: say 1. D-Bus mediation lands in Linux > 4.15 (totally made up, but this would be nice!); 2. I run Debian > Stretch; 3. I have to run Linux 4.15+ from stretch-backports (e.g. > on a shiny laptop that needs recent drivers). Then any AppArmor > profile shipped in Debian Stretch that was developed without D-Bus > mediation in mind can potentially start breaking the application > it confines. > This is true, hence the suggestion to pin the feature set by setting the features file in parser.conf This would prevent policy from enforcing the dbus feature, and prevent the application from breaking. I will admit this is not ideal because it applies to all policy loaded in the namespace (a container could have its own parser and flags) unless policy is manually loaded with a flag to override it. Which prevents policy that has been developed with the new feature from taking advantage of it in this scenario. There is some work to expose the feature set to policy which will let policy conditionally choose which features it supports but I can't promise when that work will land. > So our questions to Ubuntu & other distros are: > How have you been dealing with such problems in the past few years? > How often did you have to update packages in a stable release in > order to fix them? > > Now, simply enabling AppArmor by default during the Buster development > cycle will give us some of the answers: given many AppArmor features > will land in Linux in the next months/years, we *will* notice if our > policy is outdated :) > So there are four separate components (kernel, userspace, policy, application) to discuss here and different potential problems, depending on the combination. - kernel: If the kernel is backported and the feature set is pinned there is a low likely hood of problems. As I addressed previously there is the potential for a kernel to make changes beyond apparmor's control that change how/what permission requests reach apparmor and this can cause problems. Thankfully in practice this has not happened often. - apparmor userspace: Baring bugs, new userspaces should just work with old kernels. Even if the feature set is not pinned, the userspace will use the old kernel's feature set, so it is equivalent to pinning. - applications: When newer versions of applications are backported they can break under old policy because they provide new features that old policy wasn't designed for. Policy must be tested and updated as part of an application backport/SRU. - policy: The backporting of policy is the most problematic. New policy shouldn't be dropped onto older appli
Re: [apparmor] Let's enable AppArmor by default (why not?)
On 11/17/2017 05:34 PM, Ben Caradoc-Davies wrote: > On 18/11/17 04:27, intrigeri wrote: >> Thanks in advance, and sorry for any inconvenience it may cause (e.g. >> the AppArmor policy for Thunderbird has various issues in sid; all of >> those I'm aware of are fixed in experimental already). > > Where "various issues" means no thunderbird external helpers work under xfce. > Not a single one, as far as I can tell. And there goes another one: what > happened to my .signature? I have filed as many bugs as I can given the time > available. I will file one more for the missing .signature, and then I am > disabling apparmor. > thank you for taking time to file bugs and provide a report here to help make the apparmor experience better. You have several options for disabling parts of apparmor policy enforcement or its enforcement entirely. You can disable individual profiles without editing them and messing up the packaging by using aa-disable sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird or by manually by manually removing the profile and dropping a symlink in /etc/apparmor.d/disable/ so for example to disable the thunderbird profile you can do sudo apparmor_parser -R /etc/apparmor.d/usr.bin.thunderbird sudo ln -s /etc/apparmor.d/usr.bin.thunderbird /etc/apparmor.d/disbale/thunderbird it is important to do the removal before adding the symlink, and as in the example above the symlink does not have to be the same name as that of the profile file. you can reverse the above by using sudo aa-enable /etc/apparmor.d/usr.bin.thunderbird or manually by removing the symlink and loading the profile sudo rm /etc/apparmor.d/disable/thunderbird audo apparmor_parser -r /etc/apparmor.d/usr.bin.thunderbird You can disable the apparmor service at the systemd level with sudo systemctl disable apparmor You can remove the apparmor package sudo apt-get remove apparmor or sudo dpkg --remove apparmor and you can also set the kernel boot parameter apparmor=0 to disable apparmor on a particular boot, or set it as part of your grub config to permanently disable it without touching the packaging * for the above examples I have used /etc/apparmor.d/ for the profile location but it could be configured to other locations like /var/lib/apparmor/ etc, it depends on the distro and sometimes the package eg. ubuntu has profiles configured to different locations depending on whether they are system profiles, snap profiles, etc.
Re: [apparmor] Let's enable AppArmor by default (why not?)
On 11/18/2017 01:59 PM, Marvin Renich wrote: > * John Johansen [171118 16:02]: >> You can disable individual profiles without editing them and messing up the >> packaging by using aa-disable > [some really good beginner stuff snipped] > > John, many thanks for these tidbits. Can they be put in a text file in > /usr/share/doc/apparmor, with a NEWS.Debian entry pointing to it, so > that when the package is pulled in, the user has some idea where to > start? Since Thunderbird seems to be one of the problem packages, > having it in a text file on the local system seems like a good idea. > yes we can certainly create the text file, its a good idea. I'll leave it up to the debian maintainer to decide on the NEWS.Debian entry but it certainly sound like a good idea to me as well. > Actually, a short beginner's guide as a text file in > /usr/share/doc/apparmor, which has more than just "how to disable a > profile" would be extremely helpful. I don't have the apparmor > knowledge to write it, though. > yeah, I will start working on the doc. Make sure it has links to more comprehensive info (the wiki, ml, some man pages, etc.)
