Mailinglist Archive: opensuse-packaging (266 mails)

< Previous Next >
[opensuse-packaging] Packaging of AppArmor profiles
Hello,

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:
http://bazaar.launchpad.net/~ubuntu-core-
dev/apparmor/master/files/head:/debian/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 \
fi

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:
%apparmor_profile_post usr.sbin.foo
(where "usr.sbin.foo" is the filename of the profile in /etc/apparmor.d)


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.

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


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


As usual: feedback welcome ;-)


Regards,

Christian Boltz

[1] or apparmor-abstractions if we decide to split the abstractions into
a separate package
--
F: Word? Was ist das?
A: Das ist wohl das Programm, das ursrpünglich einmal Text heißen
sollte. Da es aber für längere Dokumente ungeeignet ist, wurde es
umbenannt. Inzwischen kann es aber bereits 97 Wörter verwalten.

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

< Previous Next >
Follow Ups