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

Fri Aug 29 15:13:23 UTC 2014

On 08/27/2014 07:23 PM, intrigeri wrote:
> 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.

I think you are giving Ubuntu developers on the whole more credit on their
AppArmor skills than is due here. :) Certainly, we have quite a few people who
understand AppArmor and are capable of adding rules, but it isn't widespread and
in most cases the security team is consulted on if it is ok to add a rule. The
nice thing about working together with Debian is that we can expand the number
of people writing policy, which is good for everyone. :)

> 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.

Most upstreams don't have profiles. This would be nice of course, but it is just
not very common. lxc, libvirt and lightdm are the only ones I can think of OTOH
and they are going to need distribution-specific changes most likely (especially
if the kernel doesn't have all the latest features).

Upstream profiles are also different than ones supplied by the Debian AppArmor
team. The former might be painful for the developer, the latter should never be
if the Debian AppArmor team is responsive. I would simply advise the Debian
developers who find AppArmor profiles in their upstream sources to approach the
Debian AppArmor team for help.

> 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.
> 
Is the goal to enable AppArmor in Debian by default? As an upstream AppArmor
developer, I would of course love to see this, but I think there would be
significant resistance from the SElinux Debian developers and I'm not sure it is
really needed. While booting an LSM is an either/or option, proper SElinux,
AppArmor, SMACK, Tomoyo, etc support in Debian is not.

Also, I don't quite understand why it has to be so painful. Ubuntu was able to
pull it off-- and again, this wasn't because all Ubuntu developers are fluent in
AppArmor, it is because a small team was responsive to the bug reports.

Furthermore, AppArmor in Debian is disabled by default so there shouldn't be
many bugs and when there are, the reporter more than likely will have updated
the policy for his/her situation since he/she opted into enabling AppArmor in
the first place (ie-- the user isn't actively broken and other users seeing the
denial can see the suggested policy update in the bug and apply it in the meantime).

All that said-- AppArmor is fairly straightforward and anyone capable of putting
together high quality Debian packages (ie Debian developers) is certainly
capable of editing and understanding AppArmor rules.

> 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.
> 
Personally, I wouldn't see this as pushing distro-wide changes. That is somewhat
adversarial. I would instead encourage the Debian AppArmor team to facilitate
adding policy to Debian packages and be a resource that Debian developers can
use. Make it easy for the Debian developers to enable and update the policy and
then eventually they might seek it out.

> 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.
> 
Right-- I think if developers want to enable AppArmor in their own packages,
they should be able to easily do so rather than having to work with the profiles
package.

I also worry that trying to push AppArmor as the default will frame the LSM
question as 'Debian must choose one'. I think that is unnecessary for Debian and
something that should be avoided. I suggest a grassroots approach: work on the
policy, make AppArmor easy for developers and users, and allow the developers to
take it up. This will garner the support and expand the number of profiles in
Debian naturally.

>>  * 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.
> 
This is where the Debian AppArmor team can be facilitators: fix and verify those
bugs and be responsive. Show that the policy verifies with a simple command (eg
'appamror_parser -QTK <policy>) and they don't even necessarily have to reboot
with AppArmor enabled if the policy compiles and the rule otherwise makes sense.

...

>>  * 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 :)
> 
Great!

> 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.
> 
Ah, I was unaware of this. Also great!

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140829/0e7363b2/attachment-0001.pgp>