Bug#846966: [pkg-apparmor] Bug#846966: evince: Please make the AppArmor profile support merged-/usr systems

[intrigeri]

Hi!

intrigeri:
> Michael Biebl:
>> Mind you, that I don't know how apparmor actually works.

> That's fine :) I'm actually very happy to see you chime in and propose
> interesting ideas!

>> This is my idea basically: say you have a apparmor profile which
>> contains /bin/foo.
>> When that profile file is read by the apparmor profile parser, you check
>> for symlinks in those paths.
>> The parser notices on a merged user system that /bin is a path to
>> /usr/bin, so it adds /bin/foo and /usr/bin/foo on the whitelist.

> This would indeed avoid patching anything for things like merged-/usr,
> /var/run and friends. The main problem I see with this approach is
> that as a side-effect, it will create rules that overlap with other
> parts of the policy, which causes various problems: 1. if such rules
> have conflicting "x" modifiers, policy compilation will fail hard
> (that's not theoretical: I've actualy hit such problems while
> preparing the patches for merged-/usr); 2. automatic "let me fix the
> policy you wrote on the fly" stuff tends to be harder to audit and
> debug (which is the main reason why I decided against using the
> existing AppArmor "alias" support to deal with merged-/usr).

> Now, I wonder if there are more problems that would come with this
> approach, that explain why it wasn't chosen. Or whether it's "just"
> a matter of lacking time to implement it… in which case it likely
> won't happen in time for Stretch, while merged-/usr will quite
> possibly be the default in there, so it would be nice to have the
> proposed patch applied :)

Upstream AppArmor expressed their disagreement with the symlinks
resolution proposed solution:
https://lists.ubuntu.com/archives/apparmor/2016-December/010360.html

So, we're back to: please apply the proposed patch :)

Cheers,
-- 
intrigeri