Mailinglist Archive: opensuse-packaging (266 mails)

< Previous Next >
Re: [opensuse-packaging] Packaging of AppArmor profiles
On Wed, Nov 07, 2012 at 10:44:45PM +0100, Christian Boltz wrote:

a short discussion with Marcus at the conference brought up an issue
with packaging AppArmor profiles:

When a package containing an AppArmor profile is installed or
updated, the profile is not (re)loaded.
This means it will only become active when the admin actively
reloads the profiles or when the machine is rebooted.
Until then, either the previous profile is used (update case) or the
application will run unprotected (if a new profile was installed).

This mail is a first draft on how to handle this.

Instead of re-inventing the wheel ;-) I asked upstream (which is
basically Ubuntu) and got the information that they use this debhelper:

The most interesting part is probably postinst-apparmor, which can be
the base for a %post macro. (IMHO creating the local/ sniplet shouldn't
be part of that macro. Maybe we should create a separate macro for it,
but that's a minor issue.)

I propose the following macro to be used in %post: (untested ;-)

%apparmor_profile_post() \
# Reload the profile, including any abstraction updates \
if aa-status --enabled 2>/dev/null; then \
apparmor_parser -r -T -W "/etc/apparmor.d/%1" || true \

This will (re)load the profile if both apparmor-utils (aa-status) and
apparmor-parser are installed and apparmor is enabled. Otherwise it will
just fail silently.

Usage in %post:
(where "" is the filename of the profile in /etc/apparmor.d)

I think this idea is good....

Another question is directory ownership of /etc/apparmor.d/ and the
availability of the abstractions and tunables (which are used by nearly
every apparmor profile).

The easiest way would be to add Requires: apparmor-profiles to every
package shipping an apparmor profile.

%dir /etc/apparmor.d/ can be done by more than one package, it would
not hurt.

Note that apparmor-profiles contains some profiles itsself, which would
then also become active (unless someone disables them manually). Do you
think this is a problem? (If yes, I can split the abstractions and
tunables into a separate package.)

And a final question: Into which package should I put the rpm macro?
(This package will then also be needed in BuildRequires:)

libapparmor-devel doesn't sound right because most packages don't need
libapparmor, and I also don't like the idea of creating an apparmor-
devel just for this file.

Remaining candidates are apparmor-profiles[1] and apparmor-parser.
apparmor-profiles[1] would have the advantage to also solve the
"unpackaged directory" warnings for /etc/apparmor.d/
(Unless someone doesn't like to have the rpm macro in the apparmor-
profiles[1] package, it's my favorite for now ;-)

We could also add it to the suse_macros file itself if we don't have a package
right now.

Maybe I'll also create another macro %apparmor_requires containing the
Requires: and BuildRequires:, but that's a technical detail ;-)
(In this case, the more interesting question is where the
%apparmor_requires macro should be packaged - storing it in an apparmor
package would cause a chicken-egg problem ;-)

Hmm, if its not planned to change much or not a lot of pacakges having it,
just leave it out I would say.

Ciao, Marcus
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >