On Wed, 2006-08-23 at 12:02 -0700, Crispin Cowan wrote:
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.
OK, this makes sense. It also explains why I never had anymore problems or even log entries after moving some profiles there.
The reason I ask is that I sometimes get errors about profiles claiming unexpected keyword: 'mr'.
[snip]
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
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.
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.
Great. I'll do some checking on the version incompatibilities and see abot getting it straightened out.
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
Ok, I'll check it out. I've been using "tail -f /var/log/audit/audit.log > /dev/tty12" when I need realtime feedback. I can pipe the other logs to other consoles through the the syslog config files but never could figure out how to get the apparmor logs to be included after I upgraded from 10.0.
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 }
The closing } is in the file, it just didn't get copied in my post. Thanks a lot for the help!