Re: Let's enable AppArmor by default (why not?)
Guido Günther:
On Sat, Sep 09, 2017 at 02:07:32PM -0700, John Johansen wrote:
>> - 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.
> This (and somewhat related the next point) is the reason why policy
> should be shipped by the application (that is the Debian package
> containing the application), not in an apparmor-profiles package. This
> makes sure the profile matches the application.
Absolutely. Here's the status / progress update on this front:
- In the last 1.5 year three profiles (Evince, ntp and tcpdump) were
moved from apparmor-profiles-extra to the corresponding package.
- apparmor-profiles ships only a few profiles currently, all of them
in complain mode; there's discussion (#830502) about what should be
done there.
- The only other apparmor* package that ships policy for other
software is apparmor-profiles-extra, which currently enforces
profiles for apt-cacher-ng, Pidgin and Totem.
I want to move them to the corresponding package during the Buster
cycle. If you want to help, I recommend starting with
usr.bin.pidgin and usr.sbin.apt-cacher-ng: both are pretty stable
and have needed very few updates in the last few years. Totem is
more complicated; it's also the one that would benefit the most
from being shipped in src:totem, provided a good workflow is set up
so users, Totem maintainers and AppArmor people are all happy.
Cheers,
--
intrigeri
Reply to: