Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1189206 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles Andrea Bolognani <eof@kiyuko.org> - 2024-03-05 23:10 +0100

#1189206 — Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles

[Multipart message — attachments visible in raw view] — view raw

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!

-- 
Andrea Bolognani <eof@kiyuko.org>
Resistance is futile, you will be garbage collected.

[toc] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web