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

[Mikhail Morfikov]

On 05/03/2024 10.53 pm, Andrea Bolognani wrote:
> On Sun, Jul 19, 2020 at 08:08:15PM +0200, Mikhail Morfikov wrote:
>> Dear Maintainer,
>>
>> Currently when the package is installed, it also installs files under
>> /etc/apparmor.d/ . There are two issues with this:
>>
>> 1) some people want to use their own profile (the local profile under
>> /etc/apparmor.d/local/ may not be an option for many reasons),
>> 2) some of the names of the files are path based, and some users could use just
>> the exec/binary name (or whatever) for the profile/file name, which leads to
>> having two different sets of rules (two different apparmor profiles loaded at
>> the same time confining the same app).
>>
>> The only way to fix this is to manually remove the provided apparmor profile
>> files after each package update, which is a little bit annoying.
>>
>> Please reconsider creating a separate package for the apparmor profile files
>> (something similar to package_name-apparmor-profile), and just
>> suggest/recommend it in deps of the main package, so the user could decide
>> whether he wants the profiles to be installed in his system or not.
> 
> Hi Mikhail,
> 
> I am currently working on a big refactoring of the libvirt package,
> which I thought could be the perfect opportunity to implement the
> split that you're suggesting here.
> 
> However, looking at the contents of the archive, it seems that the
> practice of shipping AppArmor profiles as separate package from the
> software that they're intended for is far from widespread:
> 
>    $ apt-cache search -n apparmor
>    apparmor - user-space parser utility for AppArmor
>    apparmor-notify - AppArmor notification system
>    apparmor-profiles - experimental profiles for AppArmor security policies
>    apparmor-utils - utilities for controlling AppArmor
>    dh-apparmor - AppArmor debhelper routines
>    libapache2-mod-apparmor - changehat AppArmor library as an Apache module
>    libapparmor-dev - AppArmor development libraries and header files
>    libapparmor1 - changehat AppArmor library
>    libpam-apparmor - changehat AppArmor library as a PAM module
>    python3-apparmor - AppArmor Python3 utility library
>    python3-libapparmor - AppArmor library Python3 bindings
>    apparmor-profiles-extra - Extra profiles for AppArmor Security policies
>    fwknop-apparmor-profile - FireWall KNock OPerator - Apparmor profile
>    uwsgi-plugin-apparmor - apparmor plugin for uwsgi
> 
> If we exclude apparmor-profiles(-extra), which by definition don't
> count as they are maintained separately from the corresponding
> applications, the only example I can see is fwknop.
> 
> This gives me pause, and makes me not particularly keen on going down
> such a lonesome path.
> 
> I'd like to understand your use case better though. Can you please
> provide concrete examples of the problematic scenarios you've
> mentioned in your original message, along with the steps that you
> currently have to perform to work around them?
> 
> Thanks in advance!
> 


Yes, I know that only few projects provide a separate package with apparmor
profiles.

I tried to change that by requesting people to do the change. But I failed,
so I stopped asking people to do this a long time ago.

Why I wanted the change?

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).

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).

Why to do this all the time when a package is updated? The solution is
simple -- not to force users to use the provided apparmor profile for the app
and allow them to decide.

That's why I tried to convince people to make a separate packages for apparmor
profiles, so users could decide whether they want the apparmor profile installed
in their systems or not.

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. But there are people
who use apparmor (and I use it extensively), for instance:

# aa-status | grep -v ^" "
apparmor module is loaded.
1042 profiles are loaded.
918 profiles are in enforce mode.
124 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
406 processes have profiles defined.
94 processes are in enforce mode.
312 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.

That's a lot of profiles, imagine how hard can it be to manage more apps (like
thunderbird) with apparmor profile included in the core app package and try to
manage 10-100 apps in the way I described earlier when they release a new version
of the apps. :] With separate apparmor profile packages there's no issue at all.

The other thing concerns the profiles itself -- they often lag far behind the app
development. So some app developer make a change in the project, this needs to
add/remove/change rules in the apparmor profiles, but the rules don't be added
instantly. Why? Because it needs testing. The needed rules will be different
depending on environment you use. So when you use KDE or GNOME, or like me just
X/Openbox, each of us would need different sets of rules, and the app developer
won't test the profiles for each possible desktop environment and its configuration.

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.

Take care, Morfik