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 <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.
- 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,
>
Reply to: