rmyster wrote:

Could someone point out the difference between the profiles stored in /etc/apparmor.d/ vs /etc/apparmor/profiles/extras/?

AppArmor is only enforcing the profiles in /etc/apparmor.d. The directory /etc/apparmor/profiles/extras has no operational effect on the machine; it is literally a pile of "extra" profiles provided for your convenience should you want to activate them, by copying them from /etc/apparmor/profiles/extras into the /etc/apparmor.d directory and restarting AppArmor.

The reason I ask is that I sometimes get errors about profiles claiming unexpected keyword: 'mr'. For example, here is one from a netstat profile:

"Loading AppArmor profiles AppArmor parser error in /etc/apparmor.d/bin.netstat at line 291: Found unexpected keyword: 'mr' Profile /etc/apparmor.d/bin.netstat failed to load"

If the bin.netstat profile is moved to the /etc/apparmor/profiles/extras/ directory, and apparmor is restarted, there isn't any error.

What you just did was effectively remove a profile with a syntax error and then re-start. Naturally this solved the syntax error, but with some unintended consequences :) If it thinks that "mr" is a syntax error, then I suspect that you have a "new" style profile that includes the 'm' (memory map) access permission mode, but you are still using the old AppArmor software. Sounds like a confused upgrade. See this post for more information http://marc.theaimsgroup.com/?l=apparmor-general&m=115477304809811&w=2

A 2nd example is illustrated with the usr.lib.postfix.pickup profile. If the profile in in /etc/apparmor.d, I get this error:

"# rcpostfix restart Shutting down mail service (Postfix) done Starting mail service (Postfix) failed"

with the following output from /var/log/audit/audit.log:

"type=APPARMOR msg=audit(1156337692.653:44): REJECTING mr access to /lib/ld-2.4.so (pickup(21068) profile /usr/lib/postfix/pickup active /usr/lib/postfix/pickup)"

This is the opposite problem, where you have an "old" profile and a new implementation of AppArmor. With the upgrade, programs need the "mr" access code to be able to memory map shared libraries.

moving usr.lib.postfix.pickup to /etc/apparmor/profiles/extras/ followed by a restart of apparmor and postfix generates no errors with a postfix restart.

Same as above: you just disabled your profile. Instead of disabling the profile, just run "aa-logprof" and it will detect the REJECT message, and ask you if you want to permit that. To fix a lot of such blockage at once, run "aa-complain /usr/lib/postfix/pickup" or "aa-complain /usr/lib/postfix/*" to put these profiles in complain mode, and come back later and run "aa-logprof" to collect a bunch of 'mr' bugs at one time.

Does moving the profile to the extras folder alter its use within apparmor or render it useless?

Yes :)

I notice that when I create a new profile it seems to get placed in /etc/apparmor.d/ but often apparmor won't restart because of the "Found unexpected keyword: 'mr'" issue or the application won't run properly due to the "REJECTING mr access" errors. Editing the profile manually sometimes works but if I later run the update profile wizard it just places the "m" back in and the application stops working due to denied access.

Something is broken in your update. If 'mr' is being reported as a syntax error, it sounds like you have new profiles and an old parser. If 'mr' codes are missing and causing REJECT messages, then you have a new AppArmor and old profiles. Both cannot be true at once, so I don't know what is wrong, but it should not be happening that way.

I added the contents of the bin.netstat profile at the bottom message for illustration purposes, but it happens with others and always seems to involve the letter 'm'. If there is no fuctional difference between the two directories, why does one give the error and the other doesn't?

On a related note, is there a way to include the contents /var/log/audit/audit.log in the /var/log/allmessages log?

I don't know enough about the LAF (Linux Audit Framework) to answer that. RTFM on LAF, and I'll research it too and see if I can find an answer, or perhaps someone else here knows how. man auditd, man auditd.conf, man ausearch, man aureport Early investigation suggests that LAF does not have a feature to re-send traffic to syslog. If so, then you would have 2 options: * Use an outboard log scraper e.g. swatch, to collect events from audit.log and push them to /var/log/yourfavoriteplace. * Disable LAF entirely. With LAF gone, AppArmor will revert to using syslog. So it will "just work" but the problem with syslog is that log messages are not atomic, and so there is a possibility of AppArmor events being corrupted, which can lead to profiling problems.

There is no line 291 in the bin.netstat file. but the bin.netstat profile contents start below:

Is the profile text you included a representative sample? Or a complete copy? If the latter, then this profile has been truncated, and the syntax error right after "mr" is the missing closing } Crispin

#include

/bin/netstat flags=(complain) { #include #include #include

capability dac_override, capability dac_read_search,

/bin/netstat rix, /etc/ld.so.cache mr, /etc/networks r, /lib/ld-2.4.so rlix, /lib/lib*so* mr, /proc r, /proc/[0-9]*/cmdline r, /proc/[0-9]*/fd r, /proc/net r, /proc/net/* r, /usr/lib/gconv/gconv-modules* mr, /usr/lib/locale/** mr,

-- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes