Il 01/10/20 17:43, kdibble ha scritto:
> I don't know to whom these should go to, or how to get them fixed.
>
> Documentation:
>
> Having read the fine manual:
>
> Neither
> man apparmor
> or
> man apparmor.d
>
> have any mention of apparmor.d/local
>
> There is no mention of proper formatting of apparmor.d/local files.
>
> At https://gitlab.com/apparmor/apparmor/-/wikis/Policy_Layout
> there is a mention of
>
> ${APPARMOR.D}/local/
> and
> |${HOME}/.apparmor/|
>
> but there does not appear to be any documentation on
> formatting of thefiles in the local subdirectory,
> which is different from the profiles.
>
> |But they also say that the Debian distribution include|s
> the documentation and Debian specific notes.
>
> So, can you trust documentation that contradicts itself?
>
>
> Profiles and packaging:
>
> FIREFOX-ESR
> There is no apparmor profile for FIREFOX-ESR
>
> There is a firefox profile in apparmor-profiles-extra.deb
> which appears to work after changing the name appropriately.
>
> MSMTP
> The apparmor profile is part of the package.
>
>
> The point of these last items is the inconsistent packaging.
>
> There should probably be a guideline that profiles go with the package
> or in a separate package.
>
> I discovered this after installing MSMTP and having it mysteriously fail
> when the log directory was changed.
>
> I imagine that I am not the first person to have the learning opportunity
> that inconsistent packaging creates.
>
> Regards,
>
> Ken
>
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>

Hi,
apparmor is the first thing I uninstall and set GRUB_CMDLINE_LINUX_DEFAULT="apparmor=0"
in /etc/default/grub (after systemd....).
I also add:

Package: apparmor*
Pin:    release n=beowulf
Pin-Priority: -1

To /etc/apt/preferences.d/preferences to avoid it being sucked in again as dependency
of some other package.
The reason is that I experienced so many subtle breakages of various packages
(e.g. unbound, haveged are the first I recall) for which the profiles are not
working or missing ort broken for my setup that I get fed up with it.
IMHO it is impossible to make correct profiles unless you analyze every single line
of code of the program you want to protect to detect the exact resources it
needs in every possible situation, code path and use case.
So you open up your boxes to unexpected behavior at best or breakage at worst.
It is also dangerous to relay on apparmor because it could give you a false sense
of security and last but not least who controls the controller?
Do we need a "Superarmor" to arm apparmor next?
Better configure your system correctly and keep it as simple as possible.
Less programs, less code, less bugs, less complexity, less configuration errors.

Just my 0,2 cents.

Ciao,
Tito