[apparmor] Should dh_apparmor disable a profile when the package that ships it is removed?

[Christian Boltz]

Hello,

Am Donnerstag, 28. April 2016, 09:43:31 CEST schrieb Andrew Pollock:
> On Wed, Apr 27, 2016 at 08:10:52PM +0200, Christian Boltz wrote:
> > Am Montag, 25. April 2016, 17:49:36 CEST schrieb Andrew Pollock:
> > > I asked this question on Debian bug #822077 and was directed here.
> > > 
> > > The maintainer script fragments that dh_apparmor generate only
> > > deal
> > > with the activation of a policy when the package is installed, and
> > > not the deactivation of it when it's removed.
> > > 
> > > For the sake of completeness, I would have thought that it should,
> > > but I presume there's some good technical reason why it doesn't?
> > I'd argue it's a way to error out on the safe side ;-)
> > 
> > The interesting case is when a program from the removed package is
> > still running. You might argue that a good package will also stop
> > the daemon it ships, but even if it does that in theory, the user
> > might have started the program in a different way - or the program
> > isn't a deamon and is always started by the user. [1]
> 
> I would say that it's common practice for a package that starts a
> daemon when it installs it to also stop the daemon when it's
> uninstalled.

Agreed for a deamon - it's unlikely that it's still running after 
removing the package.

What about other programs that typically get started by the user, for 
example Firefox? Or someone does a distribution update that uninstalls 
Iceweasel (and replaces it with Firefox) while Iceweasel is still 
running? I seriously hope uninstalling Iceweasel or Firefox does not 
kill a running process ;-)

I could ask the same about chromium, evolution, pidgin, totem etc.

Or look at MySQL - typicallly you'll expect a running daemon, which will 
also be stopped when uninstalling the package. Things become interesting 
when people use KDE with KMail etc. because it uses MySQL for storage 
[1] and typically starts MySQL under the user's account. This MySQL 
instance won't be stopped when uninstalling the package.

(I assume/hope people won't uninstall software they use and need, but 
I've seen differences between common sense and real life too often...)

> > Unloading the profile of a running program means to remove all
> > AppArmor restrictions from it, so the program is suddenly allowed
> > to do everything. That's probably not what you want ;-)
> 
> But it is if you've removed the package that supplied the policy.
> After the next reboot the policy isn't going to be applicable, right?
> So you've got a situation where there's inconsistent behaviour before
> and after a reboot.

A program can also still be running after removing it. Does that also 
count as inconsistent behaviour? Would removing the AppArmor 
restrictions from it make it more or less consistent? ;-)

Oh, and please show me a way to start the removed program after the 
reboot ;-)  *SCNR*

</sarcasm>

> > OTOH, by not unloading the profile we risk that you install a
> > different program with the same binary name, and that program
> > accidently gets restricted by the still-loaded AppArmor profile.
> 
> I think this is a pretty contrived risk.

Indeed, this is unlikely - which also makes it unlikely that a still 
loaded profile hurts.


So to sum it up - both ways have pros and cons, and not unloading the 
profile is the more secure choice.


Regards,

Christian Boltz

[1] extremely simplified (the Akonadi backend uses a mix of MySQL and
    files) - but you should get the point
-- 
seccheck runs here on a host that contains 3 daily backups of 10+ SAP
hosts, and the "Local Monthly Security" Mail size is 562 MB. This mail
size causes an unfriednly, suspicious grin on the face of my mail
admin... [Werner Flamme in opensuse-security]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160428/acd9063f/attachment.pgp>