[Pkg-libvirt-maintainers] Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles

[Mikhail Morfikov]

On 17/03/2024 5.18 pm, Andrea Bolognani wrote:
> On Wed, Mar 06, 2024 at 08:34:59AM +0100, Mikhail Morfikov wrote:
>> Take a look for example at the thunderbird email client package. They ship
>> the apparmor profile for the app in the thunderbird package (I also asked them
>> to do the move, but no one cared, see #949649 from 23 Jan 2020 -- no one ever
>> answered).
> 
> That bug report looks identical to the one you've filed against
> libvirt, so it doesn't provide any additional information.
> 
>> So I use thunderbird and I have my own separate profile for this app because
>> I have different rules, aiming different security policy. Each time the
>> thunderbird package is updated, the apparmor profile is also installed, and
>> I have no option to forbid that. So the apparmor policy is rewritten, which
>> requires me to manually remove the newly installed thunderbird profile (the
>> physical file), remove non exising profiles from apparmor (aa-remove-unknown),
>> reload my own profile, update initramfs (since I load the apparmor policy during
>> initramfs phase).
> 
> That does indeed sound very annoying.
> 
> I wonder why you have to go through that whole process though. The
> AppArmor configuration is in /etc, so everything is marked as
> conffiles. If you make local customizations, shouldn't you at worst
> be prompted to confirm whether you want your changes to be preserved
> or overwritten?

It's because of the naming scheme. Some time ago, apparmor changed the naming
scheme from the path (like usr.bin.thunderbird) to just the name of the app/binary
(thunderbird). And most of the app still have the old naming.

So as you can see, even when apps have apparmor profiles, no one even cares about
having them updated -- this is the main reason I wanted them in separate packages.

I have many profiles and all of them have the new naming scheme, and in such
case, apps like thunderbird simply install new files with each update, which I have
to remove and do all the stuff I described earlier.

> 
>> Most of people don't even use apparmor, so they don't care whether the profile is
>> in the core package, or in some app-apparmor-profile package.
> 
> I don't think this is a fair assessment: AppArmor is enabled by
> default in Debian and has been for several releases, so people *are*
> in fact using AppArmor unless they go out of their way to disable it.

Even when it's enabled by default, it doesn't really matter when people don't know
what apparmor is and when all profiles are in the complain mode. Try to enforce all
of the installed profiles by default and see what happens. :]

> 
>> The all issues/problems call for a separate apparmor profile packages, but someone
>> has to make that move first, so others would follow. 4 years has passed and no one
>> did this, because no one care, and no one really use apparmor. And I bet no one will
>> make that first step and in the next 4 years the problems will still persist.
> 
> Have you raised the topic on a project-wide forum, such as
> debian-devel? That would IMO be the best way forward. Convince the
> project that AppArmor profiles should be packaged separately, and
> make that into a (mini-)policy that is officially adopted.
> 
> Opening bug reports against individual packages when no project-wide
> consensus has been reached is unlikely to result in much progress.
> 

No I haven't. At that time (several years ago) there were just a couple of apps which
were shipping apparmor profiles in the core app package. Since no one really answered me
at that time, I just let it go because I had the feeling that no one really cares of
such thing like apparmor, so I stopped asking people and simply got over it.