[pkg-apparmor] Bug#989193: Bug#989193: breaks apt-cacher-ng by blocking link operation

[intrigeri]

Control: severity -1 serious

Hi,

Eduard Bloch (2021-06-08):
> I set it RC because it deliberately breaks other package's (legal)
> operations,

The whole purpose of AppArmor policy is to restrict operations to
a pre-defined set. This package does nothing else than shipping opt-in
extra AppArmor policy so its whole point is to restrict operations.
Some of the forbidden operations may be, or become, legit: that's
a bug (or a conscious trade-off) of AppArmor policy.

If you combine these with your reasoning, then any bug in AppArmor
policy that makes it block a legit operation, would be RC: I don't
think this is a reasonable way to approach bug severity for AppArmor
policy, because basically it would make bug severity a constant, and
thus we can't use it anymore to prioritize our work, do release
management, etc.

Instead, the way we do it usually is to take into account the impact
and risk of occurrence of such bugs. Which is why I asked for more
information here :)

> and installing such booby traps was not properly announced.

I'm sorry I did not let you know that we were shipping AppArmor policy
for apt-cacher-ng in apparmor-profiles-extra. I'm grateful that
Laurent Bigonville did in July 2019 (#932177), though.

I would appreciate if you used language less loaded than "booby traps"
to express your thoughts here: as I understand it, a booby trap is
meant to intentionally cause harm., which is _not_ my intention here.

One thing to keep in mind here: apparmor-profiles-extra is opt-in.
Users who have it installed intentionally decided to have more
programs confined by AppArmor.

> And because you take away the control over the package's behavior
> from the maintainers and push them to "collaboration" […]. In a way
> I don't like (shoot first, ask later).

Point taken.

I understand parts of your concerns here are more general than "breaks
apt-cacher-ng by blocking link operation". Would some help from me,
towards solving #932177 post-Bullseye, be sufficient to reach
a mutually agreeable solution? I'm also open to removing the
apt-cacher-ng profile from apparmor-profiles-extra, without blocking
on #932177, if you prefer: I don't want to force AppArmor policy on
you. This is negotiable.

>> I can't find traces of such denials in my logs.
>
> Please. Just because you don't see issues does not mean that issues
> don't exist.

Of course. This is precisely why I asked you to help me understand
in which cases these issues do exist, so I can assess severity.

>> Could you please help me understand what kind of apt-cacher-ng
>> operations (or configuration) trigger these denials and are broken by
>> the current AppArmor policy?
>
> When the mentioned mechanism was put in place, regular operation started
> breaking. This also affects the expiration jobs, therefore your cache
> will keep growing when users use non-stable distros.

OK, then indeed I think this bug is RC. Thanks!

> Or what exactly did make you think that "rw" is okay and everything
> else can be dumped? Where are we? "I see all cars on my road are
> driving straight, means that we can remove all steering wheels"?
> *facepalm*

I hear you're unhappy and perhaps angry, but I think you're out of
line here. This tone hurts and makes it more difficult and costly for
me to keep striving for constructive communication and collaboration.

Given the tone of this last paragraph, I'll assume these are
rhetorical questions and won't spend time answering them. However, if
you're genuinely interested in understanding why the profile has "rw"
and not "allow everything", I'll happy to shed some light on how
I usually develop AppArmor policy.

Cheers!