Wednesday, September 24, 2008

Doctor, I've got audit complaints about my kernel log.

AppArmor, introduced to Ubuntu with Gutsy, is yet another security tool unleashed upon the infosphere. In part, AppArmor is intended as an alternative to SELinux, which can easily be seen as daunting to configure; unfortunately, many such projects are daunting for those admins forced to walk the plank of unfamiliarity above a sea of expectations. Despite a troubled history, the project seems to be here to stay so it is likely only a matter of time before audit messages crop up in one's kernel log. For those who find AppArmor unnecessary, unpalatable, or just untimely, herein lies a quick-and-dirty guide for telling AppArmor where to stick its audit complaints.

Ubuntu's community documentation has some basic commands for starting, stopping, disabling, and enabling AppArmor, but if we want to know as little as possible about AppArmor then it's not unlikely that we're just trying to dispense with a plethora of audit complaints in our kernel log. The first time this happened to me, it was on a box which had some MySQL data in a nonstandard location, resulting in a flood of log entries similar to:

Sep 23 11:22:17 bluebeard kernel: [4960023.353512]
audit(1222183337.704:68500): type=1502
operation="inode_permission" requested_mask="r::"
denied_mask="r::" name="/u1/mysql/"
pid=1573 profile="/usr/sbin/mysqld"
namespace="default"


To allow mysqld to do its thing in /u1/mysql without sending AppArmor into a conniption fit, just add permissions to its profile, located by default at /etc/apparmor.d/usr.sbin.mysqld on Ubuntu Hardy systems.

# custom permissions
/u1/mysql/ r,
/u1/mysql/** rwk,


The first line is a comment which makes clear that the lines which follow are not default permissions. The second line grants read access to /u1/mysql/, which AppArmor expects to be a directory due to the trailing slash. The final line uses the /** syntax to specify a group of files and subdirectories, to which are granted access to read, write, and perform locking operations. Note that these rules were simply adapted from the default rules for /var/lib/mysql; such “cut-and-paste” adaptation helps avoid typos and lessens the need for a detailed understanding of the configuration syntax. Note further that this is an observation rather than a recommendation.

Once all profiles have been edited to perfection, reload AppArmor and we're off to the races.

sudo /etc/init.d/apparmor reload

When this information proves inadequate, complete documentation and additional resources can be found at OpenSuse.

No comments:

Post a Comment