[apparmor] AppArmor for wordpress

[John Johansen]

On 03/29/2018 03:47 PM, Craig Small wrote:
> Hi There,
>   As the Debian WordPress maintainer,considering WordPress has the most security bugs of all the packages I maintain I thought having an AppArmor profile for it would be a good idea.
> 
> I have now written one and done some testing and it seems to work nicely. The problem is, what to do with it?
> It basically has two files: 
>  * /etc/apache2/conf-available/wordpress which has the AAHatName in the <directory> stanzas
>  * /etc/apparmor.d/apache2.d/wordpress which defines the ^wordpress profile
> 
> The profile is highly dependent on what the user sets the WP_CONTENT_DIR to (which has to match the second <directory> stanza).
> So, it works for me.
> 
> Should I just put it in the examples file? My concern is people do odd configurations to their wordpress setup which apparmor won't like.
> 
> I'm not subscribed to this email list so please CC in your replies.
> 
Hi Craig,

with something like wordpress or really any application that is highly
configurable we don't usually recommend that it is turned on by
default, at least not at first. It can be very frustrating for your
end users who don't know what is happening and also for you having to
deal with the bug reports. Shipping it as part of the examples is a
good first step, if you want you could also submitted to the apparmor
profiles repository (https://gitlab.com/apparmor/apparmor-profiles) so
that it becomes available to the wider apparmor community.

Other options could be shipping the profile in complain mode, so it is
used but not enforced which is good for profile development, but may
end up flooding users with log messages if they make certain larger
changes. Enabling the profile by default but updating the config files
with comments directing the end user to update the apparmor profile if
they change certain config options. Or creating a utility that can
modify the profile based on config file changes (suse have done this
for samba).

What ever you chose I would recommend proceeding cautiously, its
better to ship it disabled and hopefully get some feedback on it, and
then maybe later enable it by default. Than enable it by default right
away and then have to deal with a lot of frustrated users.