[apparmor] Should dh_apparmor disable a profile when the package that ships it is removed?
apparmor at cboltz.de
Thu Apr 28 17:25:51 UTC 2016
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. 
> 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
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
 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*
> > 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.
 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...
Size: 819 bytes
Desc: This is a digitally signed message part.
More information about the AppArmor