[pkg-apparmor] Bug#918548: Bug#918548: Bug#918548: About possibility to translate AppArmor tunables

[intrigeri]

Hi,

(Meta: here I'm wearing my "maintainer triaging a newly filed RC bug"
hat; once this is done, if the resulting severity is high enough, I'll
spend some time thinking about solutions.)

Jamie Strandboge:
> I don't have all the context since the bug only has part of the thread, but I
> can say two things:

FTR the thread started there:
https://lists.debian.org/msgid-search/0ff6099c-f34c-927d-ad08-6e308091de81@gmail.com

> On Mon, 07 Jan 2019, Ian Jackson wrote:
>> To the AppArmor maintainers:
>> 
>> I have filed this as `serious' not to try to force you to fix this,
>> but because this bug seems like it will cause AppArmor to work badly
>> for many people and I felt you would want me to be sure
>> you noticed.

ACK, thank you Ian!

>> So please adjust the severity as you like.

Will do while merging with #883948.

>> I hope everyone finds my intervention helpful.

It's definitely been helpful to bump this on my radar.

In passing: Vincas is part of the AppArmor team in Debian and an
upstream AppArmor committer. So I would hope he feels legitimate to
raise issues within the AppArmor upstream and Debian teams. Now,
seniority and other factors definitely create power imbalances, so I'm
glad to see other people weighing in, sharing their views, and
supporting Vincas' request in a perhaps slightly more pressing manner
than he would dare to :)

> As for the seriousness of the bug, I'll let the Debian apparmor devs decide but
> will say that this issue has been known for many years in Ubuntu where apparmor
> is on by default and the current upstream mechanisms have proved 'ok enough'.

I concur: if the resulting UX is good enough for Ubuntu and for
openSUSE, given neither of them have a clever solution to this
problem¹, then I suspect it'll be good enough for Debian users
as well.

> I'll speculate and say this probably has something to do with the fact that the
> @{XDG_*_DIR} variables aren't widely used in system-shipped policy and what is
> left is sysadmin created policy and if the sysadmin is writing the policy, the
> man page is likely consulted.

Debian Code Search suggests² that these variables are indeed only used
in files shipped by src:apparmor, namely: the user-download and
user-write abstractions, which are themselves used³ in:

 - src:qutebrowser, where it's an example profile shipped in the
   upstream source, but not installed by the Debian binary packages.

 - usr.bin.pidgin, shipped by apparmor-profiles-extra (i.e.
   using Pidgin is not enough to have it: one must consciously opt-in
   for this additional policy); I guess this is about sending and
   receiving files, for those chat protocols that support it; this
   profile has been as-is since the first upload, 4.5 years ago, and
   AFAIK nobody complained.

 - a few "extra" profiles shipped by the apparmor-profiles package,
   which is also opt-in; that package labels these profiles as
   experimental and does not enable them by default.

If I got my codesearch query wrong, I'll be happy to stand corrected.

Last data point: no practical consequence of this (very real) issue
has been reported to the BTS since AppArmor was enabled by default in
testing/sid, 14 months ago. The only person who mentioned it was
Vincas, i.e. an experienced AppArmor policy developer, who has dived
deep enough into the policy to notice the problem.

⇒ This problem should affect no Debian user but those who consciously
opt in for stricter AppArmor policy than the default one; and even for
those who do opt in, the impact is pretty limited in scope and
severity. I think this problem currently affects AppArmor policy
developers more than users.

[1] https://bugs.debian.org/883948#20 and https://bugs.debian.org/883948#25
[2] https://codesearch.debian.net/search?q=%40%7BXDG_
[3] https://codesearch.debian.net/search?q=abstractions%2Fuser-%28download%7Cwrite%29

Cheers,
-- 
intrigeri