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
