Re: Let's enable AppArmor by default (why not?)

[Guido Günther <agx@sigxcpu.org>]

Hi John,

very interesting read!

On Sat, Sep 09, 2017 at 02:07:32PM -0700, John Johansen wrote:
> 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 <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.
> > 
> >> [...]
> >> 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.

This (and somewhat related the next point) is the reason why policy
should be shipped by the application (that is the Debian package
containing the application), not in an apparmor-profiles package. This
makes sure the profile matches the application. Everything else calls
out for trouble.

Cheers,
 -- Guido

> 
> - policy: The backporting of policy is the most problematic. New
>   policy shouldn't be dropped onto older applications without testing.
> 
>   Also new policy may make use of features that are not supported by
>   an older userspace. In this case policy should be adjusted or a
>   newer apparmor userspace can be used.  If the feature set is pinned
>   the apparmor userspace can gracefully downgrade unsupported features
>   so that new policy can work on older feature sets (you can also
>   configure it to warn or abort).
> 
>   The single biggest problem is applications that would like to share
>   a single policy across multiple releases. Ie.  they only want to
>   maintain a single policy for Stretch, and Buster but Stretch
>   apparmor userspace doesn't support some feature required in Buster.
> 
>   Currently this requires backporting a newer apparmor userspace and
>   pinning of the feature set if the kernel changes.
> 
>   There is work in progress to allow older parsers to recognize and
>   downgrade new features without directly supporting them but I can
>   not say when this will land.
> 
> 
> Speaking from experience with Ubuntu, the kernel backports are seldom
> problematic. We have seen the most issues around application
> backports; either policy needing to be updated if it is not shipped as
> part of the application, or the application policy requiring features
> not supported by the apparmor userspace. This can be dealt with by
> either editing the policy or backporting a newer apparmor userspace.
> 
> These issues should be and generally are caught during the SRU
> process.
> 
> >>>> 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
> > 
> > Do you mean /etc/apparmor/parser.conf?
> > I can't find anything related in subdomain.conf(5).
> > 
> 
> ah yep, oops there used to be a subdomain.conf, back before Novell
> renamed the project to AppArmor.
> 
> >> would be better as then you don't have to mess with initscripts, unit
> >> files, etc.
> > 
> > Absolutely. I guess we would want a package built from src:apparmor to
> > ship that conffile containing "features-file XYZ", where XYZ encodes
> > the feature set supported by the policy in the version of Debian this
> > src:apparmor was built for. Which raises a number of technical and
> > policy questions, not all of them trivial, so I want to first check
> > whether we really need to go that far (see above).
> > 
> >> 4.14 - isn't fully decided yet, but it should pickup everything except
> >>        maybe the extended unix socket mediation
> > 
> > Just curious: does this "everything except" include D-Bus mediation?
> > 
> 
> No D-Bus mediation depends on the extended unix domain socket
> mediation.
> 
> And I can now say that the extended unix socket mediation didn't make
> it into 4.14 but everything else did. So you can use basic af socket
> rules.
> 
> >> There is recognition that this was the wrong approach and there is
> >> now an upstream first policy.
> > 
> > This, along with the vivid collaboration I see between the GNOME and
> > Ubuntu projects these days, is very good news :)
> > 
> > Cheers,
> > 
>