Debian Bug report logs - #830502
apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: intrigeri@debian.org

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Fri, 08 Jul 2016 18:05:26 +0200

Package: apparmor-profiles
Version: 2.10.95-4
Severity: normal

The apparmor-profiles package ships a number of profiles in
/etc/apparmor.d/, "in complain mode so that users can test and choose
which are desired". This includes policy for dovecot, dnsmasq,
avahi-daemon, ping.

This is confusing to some of us, and to users in general. And IIRC
Felix had some concerns about shipping these profiles there as well.

During the team meeting we had at DebConf, several options were
suggested:

a) Move the profiles that are not good enough to be enforced to
   a separate package

b) Move the profiles that are not good enough to be enforced to
   /usr/share/doc (where we already ship a number of profiles)

Also, it might be that some of these profiles are actually good enough
to be enforced by default, instead of being moved elsewhere.

Apparently, I've volunteered to work on that, but help would be
greatly welcome :)

Next step is to check what other distros (Ubuntu, OpenSUSE) do about
these profiles.

Cheers,
--
intrigeri

Message #10 received at 830502@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 830502@bugs.debian.org

Cc: anarcat@orangeseeds.org

Subject: Re: Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Tue, 04 Jul 2017 09:52:55 +0200

Hi,

intrigeri@debian.org:
> The apparmor-profiles package ships a number of profiles in
> /etc/apparmor.d/, "in complain mode so that users can test and choose
> which are desired". This includes policy for dovecot, dnsmasq,
> avahi-daemon, ping.

> This is confusing to some of us, and to users in general. And IIRC
> Felix had some concerns about shipping these profiles there as well.

> During the team meeting we had at DebConf, several options were
> suggested:

> a) Move the profiles that are not good enough to be enforced to
>    a separate package

> b) Move the profiles that are not good enough to be enforced to
>    /usr/share/doc (where we already ship a number of profiles)

> Also, it might be that some of these profiles are actually good enough
> to be enforced by default, instead of being moved elsewhere.

I'm adding Antoine in the loop as he suggested on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866790#19 that we do the opposite,
i.e. to ship profiles from /usr/share/doc/apparmor-profiles/extras/ in
/etc/apparmor.d/ in complain mode. It seems we have good reasons to
move policy that's not quite ready for production use out of
/etc/apparmor.d/ (this is what this bug was about originally), but we
also have good reasons to do the exact opposite.

Advantages of shipping not-quite-ready-yet profiles (in complain mode)
in /etc/apparmor.d/:

 * users who want to use some of these profiles simply have to
   aa-enforce them, and they'll automatically get updated versions
   when they upgrade apparmor-profiles; FTR the current situation is
   that these users *copy* those profiles to /etc and then report bugs
   about their obsolete copy (e.g. #866790), which is confusing to
   users and adds extra maintenance workload on our team;

 * giving these profiles more exposure to testing might encourage some
   users to improve them upstream.

Drawbacks of shipping not-quite-ready-yet profiles (in complain mode)
in /etc/apparmor.d/:

 * it's hard to communicate to users the quality of these profiles,
   and where bugs/improvements shall be submitted; currently we have
   /usr/share/doc/apparmor-profiles/extras/README that states clearly
   that these profiles "are not as mature as the profiles in
   /etc/apparmor.d/", and that improvements shall be submitted
   directly upstream. If we were shipping these profiles in /etc, I'm
   worried we would get even more bug reports about them in the Debian
   BTS, which causes 1. extra workload on our team; 2. frustration for
   the user (being redirected to yet another BTS after reporting a bug
   discourages many people, while perhaps they would send their
   proposed changes directly upstream if instructed to do so in the
   first place)

I have to say I'm torn between these two options. What do my fellow
team-mates think?

Cheers,
-- 
intrigeri

Message #15 received at 830502@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@orangeseeds.org>

To: intrigeri <intrigeri@debian.org>, 830502@bugs.debian.org

Subject: Re: Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Tue, 04 Jul 2017 10:55:06 -0400

On 2017-07-04 09:52:55, intrigeri wrote:
> Hi,
>
> intrigeri@debian.org:
>> The apparmor-profiles package ships a number of profiles in
>> /etc/apparmor.d/, "in complain mode so that users can test and choose
>> which are desired". This includes policy for dovecot, dnsmasq,
>> avahi-daemon, ping.
>
>> This is confusing to some of us, and to users in general. And IIRC
>> Felix had some concerns about shipping these profiles there as well.
>
>> During the team meeting we had at DebConf, several options were
>> suggested:
>
>> a) Move the profiles that are not good enough to be enforced to
>>    a separate package
>
>> b) Move the profiles that are not good enough to be enforced to
>>    /usr/share/doc (where we already ship a number of profiles)
>
>> Also, it might be that some of these profiles are actually good enough
>> to be enforced by default, instead of being moved elsewhere.
>
> I'm adding Antoine in the loop as he suggested on
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866790#19 that we do the opposite,
> i.e. to ship profiles from /usr/share/doc/apparmor-profiles/extras/ in
> /etc/apparmor.d/ in complain mode. It seems we have good reasons to
> move policy that's not quite ready for production use out of
> /etc/apparmor.d/ (this is what this bug was about originally), but we
> also have good reasons to do the exact opposite.
>
> Advantages of shipping not-quite-ready-yet profiles (in complain mode)
> in /etc/apparmor.d/:
>
>  * users who want to use some of these profiles simply have to
>    aa-enforce them, and they'll automatically get updated versions
>    when they upgrade apparmor-profiles; FTR the current situation is
>    that these users *copy* those profiles to /etc and then report bugs
>    about their obsolete copy (e.g. #866790), which is confusing to
>    users and adds extra maintenance workload on our team;
>
>  * giving these profiles more exposure to testing might encourage some
>    users to improve them upstream.
>
> Drawbacks of shipping not-quite-ready-yet profiles (in complain mode)
> in /etc/apparmor.d/:
>
>  * it's hard to communicate to users the quality of these profiles,
>    and where bugs/improvements shall be submitted; currently we have
>    /usr/share/doc/apparmor-profiles/extras/README that states clearly
>    that these profiles "are not as mature as the profiles in
>    /etc/apparmor.d/", and that improvements shall be submitted
>    directly upstream. If we were shipping these profiles in /etc, I'm
>    worried we would get even more bug reports about them in the Debian
>    BTS, which causes 1. extra workload on our team; 2. frustration for
>    the user (being redirected to yet another BTS after reporting a bug
>    discourages many people, while perhaps they would send their
>    proposed changes directly upstream if instructed to do so in the
>    first place)

My counter-argument here would be that I would *assume* a profile in
"complain" mode is not production ready, by definition.

The problem with people filing bugs directly in the BTS is a false
problem, in my opinion: you'll always get this, regardless of how you
set things up. Obfuscating the profiles in /usr/share hasn't helped you
with my bug report, and I consider myself a rather experienced user. I
even *knew* about that policy before and *read* that README file, all
the way back when I deployed those profiles, and I simply forgot about it.

A more productive way of pre-triaging bug reports is with reportbug
hooks, to make sure users are made aware, when reporting bugs, what they
should report upstream. For example, the file
"/usr/share/bug/$package/presubj" is shown to the user before asking for
the subject. You can even interactively prompt the user for stuff... See
the docs here for details:

/usr/share/doc/reportbug/README.developers.gz

Such a prompt would have certainly given me pause when reporting a bug
against apparmor-profiles-extra...

In other words, I think shipping profiles in /usr/share is the wrong
solution to this problem. Proper packaging of those profiles should
install them in /etc/apparmor.d, otherwise they do not bring a
significant enough advantage for me to use them over directly getting
them from upstream (other than the maintainers' verification and trust
path, naturally). Bug pre-triaging problems can be solved in other ways.

Thanks!

A.

-- 
Nothing in life is to be feared, it is only to be understood
Now is the time to understand more, so that we may fear less.
                         - Marie Curie

Message #20 received at 830502@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 830502@bugs.debian.org

Subject: Re: Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Thu, 10 Aug 2017 16:49:09 -0400

intrigeri:
> Drawbacks of shipping not-quite-ready-yet profiles (in complain mode)
> in /etc/apparmor.d/:

Here's another one, that might be a deal breaker:

 * 'deny' rules are enforced even in complain mode, so *all* AppArmor
   users are affected by any bug in such rules

Message #25 received at 830502@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 830502@bugs.debian.org

Subject: Fwd: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Thu, 10 Aug 2017 16:43:34 -0400

[Message part 1 (text/plain, inline)]

(forwarding Seth's reply to the bug report)

[Message part 2 (message/rfc822, inline)]

From: Seth Arnold <seth.arnold@canonical.com>

To: pkg-apparmor-team@lists.alioth.debian.org

Subject: Re: [pkg-apparmor] Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Wed, 5 Jul 2017 16:20:26 -0700

[Message part 3 (text/plain, inline)]

On Tue, Jul 04, 2017 at 09:52:55AM +0200, intrigeri wrote:
> Drawbacks of shipping not-quite-ready-yet profiles (in complain mode)
> in /etc/apparmor.d/:
> 
>  * it's hard to communicate to users the quality of these profiles,
>    and where bugs/improvements shall be submitted; currently we have

Complain-mode profiles can also have significant performance penalties:

- Verbose logging can steal IOPS and keep hard drives from going to sleep.

- Missing 'x' rules can lead to enormous kernel memory use due to
  auto-generated //null- profiles.

- The kernel memory pressure can induce premature swapping which hurts
  extra hard when the log files are seeing constant IO.

There's not much middle ground between "good enough to be enabled by
default" and "should not be enabled by default". If we don't trust it
to be correct for the vast majority of users, we shouldn't enable it by
default, even if unconfined. The penalties for those few can be pretty
steep and that leads to turning off AppArmor entirely rather than just
the one profile that's not ready.

Thanks

[signature.asc (application/pgp-signature, inline)]

[Message part 5 (text/plain, inline)]

_______________________________________________
pkg-apparmor-team mailing list
pkg-apparmor-team@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/pkg-apparmor-team

[Message part 6 (text/plain, inline)]

-- 
intrigeri

Message #30 received at 830502@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 830502@bugs.debian.org, Antoine Beaupré <anarcat@orangeseeds.org>

Subject: Re: Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Thu, 10 Aug 2017 17:50:41 -0400

Hi,

I've re-read the bug log and taken a step back. Here's some context
and a proposal. Please provide input/opinions; especially Ubuntu
people are welcome to comment: I want to do something that works for
them as well (saying "we don't care much about this package, do
whatever you want and we'll pull it as-is" is a valid option).

Context: this is about the apparmor-profiles package, that has no
reverse-dependency, so this whole thing is not such a big deal (users
won't be affected unless they voluntarily install this package).
This package ships policy in /etc/apparmor.d/ (loaded, in so-called
complain mode i.e. not enforced except 'deny' rules), and some more in
/usr/share/doc/apparmor-profiles/extras/ (not loaded at all).

IMO the primary short-term goal of shipping this package at all in
Debian/Ubuntu is to encourage enthusiast AppArmor users on Debian,
Ubuntu and derivatives to improve WIP, shared profiles that live in
the upstream AppArmor bzr repo, instead of writing their own from
scratch. As Antoine explained, we currently do a poor job at this with
this package.

And the long-term goal is that eventually, some of these shared
profiles might become good enough to be shipped in the apparmor
package and enforced by default (and others should simply dropped from
Debian-based distros if nobody cares enough to make them work on
Debian and maintain them proactively).

I propose we pick some low-hanging fruits to better achieve these
goals without hindering our other, perhaps more important WIP efforts:

1. Rephrase the description of this package to better express what
   users are entitled to expect from the policy it ships.

   (Giving the package a less misleading name would be even better,
   but that would require more work spread over many wikis/doc pages
   so let's not bother for now.)

2. Install *all* the profiles shipped by this package to
   /etc/apparmor.d/, set it in complain mode.

   (Once it's been clarified what this package is about, let's smooth
   the "get started with contributing to these profiles" process.)

3. Take advantage of reportbug mechanisms (as suggested by Antoine) to
   help users report bugs and contribute patches about this policy to
   better places than the Debian BTS.

4. Go back to the broader "have better tools & processes to do
   cross-distro profiles maintenance" topic.

Cheers,
-- 
intrigeri

Message #35 received at 830502@bugs.debian.org (full text, mbox, reply):

From: Seth Arnold <seth.arnold@canonical.com>

To: intrigeri <intrigeri@debian.org>, 830502@bugs.debian.org

Subject: Re: [pkg-apparmor] Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Thu, 10 Aug 2017 18:12:13 -0700

[Message part 1 (text/plain, inline)]

On Thu, Aug 10, 2017 at 05:50:41PM -0400, intrigeri wrote:
> Context: this is about the apparmor-profiles package, that has no
> reverse-dependency, so this whole thing is not such a big deal (users
> [...]
> 2. Install *all* the profiles shipped by this package to
>    /etc/apparmor.d/, set it in complain mode.
> 
>    (Once it's been clarified what this package is about, let's smooth
>    the "get started with contributing to these profiles" process.)

The quality levels of the profiles in this package -- and their relevance
to modern systems -- is probably too varied at this point to suggest
turning them all on in any capacity by default. If Someone were to go
through them with an eye towards heavily pruning what should be pruned
first, this might be a reasonable idea.

I think I'd rather they all be installed on the side though, and perhaps
suggested by the tools, if they don't already.

It would be nice to have more examples that we're not ashamed of more
widely available :)

Thanks

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 830502@bugs.debian.org (full text, mbox, reply):

From: Jamie Strandboge <jamie@canonical.com>

To: intrigeri <intrigeri@debian.org>, 830502@bugs.debian.org, Antoine Beaupré <anarcat@orangeseeds.org>

Subject: Re: [pkg-apparmor] Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Fri, 11 Aug 2017 08:21:06 -0500

[Message part 1 (text/plain, inline)]

On Thu, 2017-08-10 at 17:50 -0400, intrigeri wrote:
> 
> And the long-term goal is that eventually, some of these shared
> profiles might become good enough to be shipped in the apparmor
> package and enforced by default (and others should simply dropped from
> Debian-based distros if nobody cares enough to make them work on
> Debian and maintain them proactively).

I agree with what Seth said, so I'll only respond on this point.

When the profiles are good enough to ship by default, Ubuntu historically has
preferred to ship profiles in the package that is under enforcement, since you
get the security policy by default (without having to opt-in to another package)
and because it allows the maintainer of the package to update the rules (ie, the
maintainer of cups need only worry about the cups package as opposed to cups and
apparmor).

This of course isn't without its problems, but wanted to clarify this point wrt
Ubuntu at least.

-- 
Jamie Strandboge             | http://www.canonical.com

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 830502@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@orangeseeds.org>

To: intrigeri <intrigeri@debian.org>, 830502@bugs.debian.org

Subject: Re: Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Fri, 11 Aug 2017 10:17:04 -0400

LGTM.
-- 
If quantum mechanics hasn't profoundly shocked you, you haven't
understood it yet.
                       - Niels Bohr

Message #50 received at 830502@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 830502@bugs.debian.org

Subject: Re: Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Thu, 18 Jan 2018 19:31:29 +0100

Hi,

Seth Arnold:
> On Thu, Aug 10, 2017 at 05:50:41PM -0400, intrigeri wrote:
>> Context: this is about the apparmor-profiles package, that has no
>> reverse-dependency, so this whole thing is not such a big deal (users
>> [...]
>> 2. Install *all* the profiles shipped by this package to
>>    /etc/apparmor.d/, set it in complain mode.
>> 
>>    (Once it's been clarified what this package is about, let's smooth
>>    the "get started with contributing to these profiles" process.)

> The quality levels of the profiles in this package -- and their relevance
> to modern systems -- is probably too varied at this point to suggest
> turning them all on in any capacity by default.

OK. This plus the fact deny rules are (confusingly) enforced in
complain mode, plus some more bug reports from somewhat confused
users, convinced me that we should not ship all these profiles in
/etc; and at the very least, not in Debian while we're still
considering enabling AppArmor by default.

> If Someone were to go through them with an eye towards heavily
> pruning what should be pruned first, this might be
> a reasonable idea.

Someone != me.

> I think I'd rather they all be installed on the side though, and perhaps
> suggested by the tools, if they don't already.

Deal.

I lack energy to handle the packaging side of moving files from /etc
to /usr right now though (conffiles to non-conffiles, sounds scary),
so in the meantime I took several steps to make the apparmor-profile
package description more humble and to stop encouraging average users
to install it at all:
https://salsa.debian.org/apparmor-team/apparmor/merge_requests/1,
merged, not uploaded yet. Same on
https://wiki.debian.org/AppArmor/HowToUse, where I also added warnings
about the deny rules vs. complain mode problem.

There's definitely more work to do on this bug but for now I'm happy
enough with the resulting state of things, that should be vastly more
sustainable than it used to for me.

Cheers,
-- 
intrigeri

Message #55 received at 830502-done@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 830502-done@bugs.debian.org

Subject: Re: Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

Date: Tue, 30 Oct 2018 11:07:54 +0100

Version: 2.12-2

> I lack energy to handle the packaging side of moving files from /etc
> to /usr right now though (conffiles to non-conffiles, sounds scary),
> so in the meantime I took several steps to make the apparmor-profile
> package description more humble and to stop encouraging average users
> to install it at all:
> https://salsa.debian.org/apparmor-team/apparmor/merge_requests/1,
> merged, not uploaded yet. Same on
> https://wiki.debian.org/AppArmor/HowToUse, where I also added warnings
> about the deny rules vs. complain mode problem.

> There's definitely more work to do on this bug but for now I'm happy
> enough with the resulting state of things, that should be vastly more
> sustainable than it used to for me.

I'll leave it at that ⇒ closing.

Send a report that this bug log contains spam.