[pkg-apparmor] RFC: draft proposal for enabling AppArmor by default in Debian

[intrigeri]

Hi,

(Meta: I'm attaching the latest version of the draft so whoever did
not read it yet does not duplicate efforts. Resisting pushing it to
a Git repo ;)

Guido Günther:
> Awesome this is moving forward!

:)

Thanks a lot for all this useful feedback.

> On Thu, Aug 03, 2017 at 05:20:20PM -0400, intrigeri wrote:
> [..snip..]
>> A proposal
>> ==========
>> 
>> 1. Enable AppArmor by default in testing/sid as soon as feasible in
>>    the Buster cycle.
>> 
>>    I can think of several possible ways to do it but for now I'd
>>    rather focus on the "do we want to do it at all" conversation.

> I read below that you don't want to go too much into the implementation
> details but do you already have a plan how to do this (i.e. to pull in
> apparmor on existing installations, will the grub package change the
> kernel command line, will it only affect new installations?) Stating the
> details somewhere (maybe on the wiki) might make things look more
> concrete.

OK, thanks. I've listed the options I have in mind on the wiki
(https://wiki.debian.org/AppArmor/Progress#Enabling_AppArmor_by_default.3F)
and added a link to it in the proposal.

>> What do other distributions do?
>> -------------------------------

[...]

> It would be great to know what this actually means like

>   * in Tails, since 2014 for all important services like …

Sure, done.

>> What's the history of AppArmor in Debian?
>> -----------------------------------------
>> 
>> AppArmor has been available (opt-in) in Debian since 2011. In 2014
>> a Debian AppArmor packaging team was created, that has been taking
>> care of the AppArmor packages and policy since then.
>> 
>> In the last 3 years the AppArmor policy shipped in Debian was extended
>> substantially and its coverage is now on par with Ubuntu's. It's still
>> rather small due to the strategy we chose: we wanted to avoid
>> traumatizing early adopters and to avoid creating a culture of
>> "AppArmor always breaks stuff, let's get used to disabling it".
>> So like Ubuntu, we're shipping a rather small and mature AppArmor
>> policy. I believe this strategy has been successful so far, but of
>> course it has one drawback: most software, including web browsers, is
>> not confined with AppArmor whatsoever. Surely with more people

> But we already have non-trivial packages that are confined
> e.g. thunderbird. Might be worth mentioning as well.

Right! Done.

>> What's the cost for package maintainers?
>> ----------------------------------------
>> 
>> Package maintainers have to deal with the aforementioned bug reports,
>> whose number is likely to grow significantly once AppArmor is enabled
>> by default. This means they have to:
>> 
>> 1. identify if a bug report can possibly be related to AppArmor;
>> 2. either learn how to debug AppArmor issues themselves, or ask for
>>    help to the pkg-apparmor team.
>> 
>> I expect that initially pkg-apparmor will need to provide help is many
>> cases, but over time the affected maintainers will slowly learn just
>> enough about AppArmor to handle at least the simplest cases
>> themselves, just like it happened in Ubuntu years ago.

> Are there docs to assist them? If so I'd link to them right away.

ACK, done yesterday after someone else made the same comment out of
band :)

>> How can I help?
>> ---------------
>> 
>>  * Enable AppArmor on your Debian systems:
>>    https://wiki.debian.org/AppArmor/HowToUse
>> 
>>  * If you maintain a package that we ship AppArmor policy for:
>>    test it with AppArmor enabled before uploading.

> This might be off topic but do you already have plans to have packages
> autpkg tested under apparmor on ci.debian.net or jenkins.debian.net. or
> similar?

Excellent question! This would make a lot of sense, and would decrease
the cost supported by users and maintainers. I definitely have some
ideas and plans in this respect, but at this point I'm not sure I can
commit to make them happen, so I initially decided not to mention it.

My best idea at this point is to help Phil Hands, who has WIP to reuse
the Tails automated testing framework for Debian, put this into
a production-ready state and extend the test coverage.

In passing, the Tails automated test suite exercises lots of software
confined by Debian's AppArmor policy; we even have some test cases
that exercise precisely the AppArmor confinement. We are currently
considering basing Tails on (quarterly snapshots of) Debian testing;
if this happens, then I expect we'll be automatically testing a branch
based on current Debian sid daily, which hopefully will allow
identifying regressions before they migrate to testing.

I'm not sure about autopkgtests. IIRC ci.debian.net uses LXC, and
I personally have no experience with testing AppArmor policy within
LXC. I know that lots of effort in AppArmor upstream was put into
"stacking", i.e. allowing a LXC guest to enforce its own AppArmor
policy to the sandboxed software. But AFAIK until very recently this
required out-of-tree kernel patches so I didn't look into it yet.

IMO all this is too vague to be mentioned in the initial proposal, but
surely the same question will arise and we'll have to answer it
anyway, so I dunno what's best. Of course, if someone (else than me)
wants to dive into this topic deeper, it would be a game changer :)

Cheers,
-- 
intrigeri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Buster_plan.mdwn
Type: text/markdown
Size: 20205 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-apparmor-team/attachments/20170804/61ae7be1/attachment.bin>