[pkg-apparmor] Bug#872266: Bug#872266: apparmor-profiles-extra: Disable profiles before uninstalling them

[intrigeri]

Control: retitle -1  dh_apparmor: when purging a package, unload profiles that confine programs shipped in other packages 

Hi!

Christian Boltz:
> Am Samstag, 9. September 2017, 20:24:40 CEST schrieb intrigeri:
> TL;DR: I'd strongly recommend *not* to unload profiles when de-installing 
> a package.

[...]

> OTOH, if you unload a profile, and a program from this package is still 
> running, unloading the profile means to remove the confinement from the 
> running program. In other words: the still-running program can now do 
> whatever it wants.

> I prefer to error out on the safe side, therefore I recommend not to 
> unload profiles on package uninstallation. The security risks this 
> prevents clearly outweight the (unlikely) problems with still-loaded 
> profiles.

Thanks, you made me realize that I haven't put enough thought into
this problem to frame it correctly.

As I see it, there are two cases:

A) Uninstalling a package that ships AppArmor policy for programs it
   *itself* ships (e.g. evince)

   Your reasoning applies and I agree we should not unload policy: if
   an instance of a confined, to-be-removed program is still running,
   then it should remain confined, both for security reasons and to
   keep UX consistent (the program came with its policy in the first
   place, they go together, and the policy shall remain applied as
   long as the program is still running). I agree that the case when
   this break another program installed in the same path is unlikely
   to happen; it can be dealt with in an ad-hoc manner if needed.

B) Uninstalling a package that ships AppArmor policy for programs
   shipped by *other* packages (e.g. apparmor-profiles*)

   The user action of uninstalling that package means "I don't want
   this AppArmor policy to apply anymore". And then it would make
   sense to me to unload the to-be-removed policy immediately, without
   requiring a reboot to actually apply the change requested by the
   user. And then I think we should do that on normal removal, not
   only when purging.

I'm therefore retitling this bug to limit its scope to case B.

Are we in agreement?

Cheers,
-- 
intrigeri