[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: