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&[email protected] > * 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 -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
