[pkg-aa-profiles-team] Centralized or distributed policy [Was: License and copyright of ~apparmor-dev/apparmor-profiles?]

[intrigeri]

Hi,

Jamie Strandboge wrote (20 Aug 2014 03:46:57 GMT) :
> [...] I think shipping policy in the affected packages is a good
> thing for several reasons:

>  * it keeps the Debian/Ubuntu developer and or team engaged with the policy
>    because they own it. With tools like dh_apparmor and new dh, it is trivial
>    to add policy to affected packages. These developers typically know the
>    package better than policy writers and are in a position to test the package
>    with new upstream releases and update the policy accordingly

I agree that this totally makes sense when AppArmor usage and
knowledge is widespread among distro developers. Unfortunately, this
is not the case yet in Debian, as AppArmor is not enabled by default,
its usage is marginal at best, and most Debian package maintainers
don't know anything about it yet. The net result is that when
maintainers get profiles from upstream (lxc, lightdm) and upload it
as-is to Debian, most of the time they're untested, and too often
they're plain broken on Debian. It's a clear loss for everyone:
package maintainers associate the "AppArmor" word with "painful bug
reports I am not able to fix", and early adopters of AppArmor in
Debian associate it with "breakage on a regular basis". Neither will
help the cause of enabling AppArmor by default in Debian, at all.

We're facing a chicken'n'egg situation here, and it's kinda hard to
push distro-wide changes in Debian without having *first* demonstrated
that it is worth it and sustainable.

That's why I've picked the following strategy: first, push more
profiles into the distro, maintain them, have more people opt-in for
AppArmor; once it's been demonstrated that $we are able to maintain
profiles that don't break functionality, and once we have enough users
who enabled AppArmor and are happy with it, then we'll want to propose
enabling AppArmor by default, and then, we'll surely want to put
profiles into the corresponding individual packages, instead of
centralizing them all in a single one.

Still, there are middle grounds, as you're suggesting later.

>  * Bugs go against the package that is affected. Not only is this natural, in
>    practice, AppArmor is easy enough for regular people to use so the bugs are
>    often either of high quality (ie, contain a patch or policy snippets to fix
>    the bug) or are easy to understand for the developer to update the policy.

I agree in principle, but unfortunately this doesn't apply to the
Debian situation yet, as explained above. In practice, as long as
AppArmor is opt-in, most package maintainers won't bother going out of
their way and enabling it, just to fix a bug (or validate a proposed
patch against the policy) that only affects a very small amount of
users. I'm sad about this, but I also see their PoV and how they're
prioritizing AppArmor compared to their other tasks, in the current
state of things.

>    We use the 'apparmor' tag in Ubuntu to make it easy for policy authors to
>    find bugs related to apparmor policy. Debian could do something similar.

Indeed, we should have such a tag => todo++ :)

We already have one for profiles that have been proposed for inclusion
in individual packages:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=new-profile&user=pkg-aa-profiles-team@lists.alioth.debian.org

>  * It ensures there is no bottleneck for adding AppArmor to packages. Eg, a
>    Debian developer need only update his/her own package rather than trying to
>    maintain the policy in a package he/she does not own. It would be a shame
>    if a developer interested in increasing the security of his/her package by
>    adding Apparmor would give up because it is too difficult to maintain in a
>    foreign package. Considering Debian's strong package ownership compared to
>    Ubuntu, this is a real concern of mine

I'm not following you on that one, and I suspect there's a little
misunderstanding wrt. what our intentions are:

1. We do *not* intend to discourage any package maintainer who cares
   about AppArmor from shipping profiles in "their" individual packages.
   If they want to do that and actually test and maintain the policy
   there, then I'm happy, less work for me, and indeed they're the
   best placed persons to maintain it :)

2. apparmor-profiles-extra is in collab-maint, which means that
   basically any Debian contributor can push to the Git repository.
   I hope that this helps mitigate the strong ownership of packages
   problem, especially since the corresponding team is also listed on
   https://wiki.debian.org/LowThresholdNmu.

> In Ubuntu, the Ubuntu Security team generally writes the initial policy. We will
> fix policy bugs too and we are often consulted by the Ubuntu developer wishing
> to fix a policy to make sure that the fix is safe. This has worked well for many
> years and I encourage Debian to do the same. Perhaps have a policy team that
> creates/refines policy, sends debdiffs to add the policy, watches for bugs (eg,
> via the 'apparmor' tag) and generally be available to answer questions. I would
> encourage the policy team to review all apparmor policy prior to Debian release
> (this is not hard to do with codesearch and/or a little scripting). This is
> pretty much what the Ubuntu Security does for Ubuntu policy.

Thanks for sharing this experience. I think the Debian AppArmor
profiles team can indeed be used this way. I'll make this clear, and
document it all for package maintainers, when we'll announce the team
(which I intend to do once apparmor-profiles-extra is in the archive).

> I would be happy to join this policy team and I'm sure others from
> Ubuntu would be too.

Woohoo, great! :)

Cheers,
-- 
intrigeri