4

My auditd rules and my needs are fairly simple, I want only to log root actions.

# auditctl -l
-a always,exit -S all -F euid=0 -F perm=x -F key=ROOT_ACTION

That is the only rule, and it works:

type=SYSCALL msg=audit(1550318220.514:11479): arch=c000003e syscall=59 success=yes exit=0 a0=56002fde79a8 a1=56002fdeffc8 a2=56002fdee3a0 a3=0 items=2 ppid=7250 pid=7251 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=1 comm="tail" exe="/usr/bin/tail" key="ROOT_ACTION"

However I also have apparmor profiles to explicitly deny certain apps privileges they do not need. This is deliberate and works as expected. However they result in my auditd.log being spammed up with stuff like:

type=AVC msg=audit(1550309442.438:207): apparmor="DENIED" operation="exec" profile="/usr/lib/slack/slack" name="/bin/dash" pid=2893 comm="slack" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

As you see that's being executed by Slack running as a non-root user, isn't being caught by my ROOT_ACTION auditd rule.

It does this a LOT:

# cat /var/log/audit/*| egrep apparmor | wc -l
40574

That's in less than 24 hours.

I realise I could use aureport and ausearch or a myriad of other methods to filter what I see. However I would prefer not to introduce the bias of only finding the weirdness I was expecting, because it's the unexpected that worries me.

So, how can I:

  1. stop auditd from appending these events to /var/log/audit/audit.log?
  2. prevent apparmor from logging denied activities in the context of an individual profile (not globally) (UPDATE, Hargut's answer below addresses this, the solution is to explicitly use 'deny' which does not log)

Help!

Nanzikambe
  • 265
  • 2
  • 8

2 Answers2

3

Loooking through the docs, it looks for me that this needs to be setup in the according apparmor profile.

http://manpages.ubuntu.com/manpages/cosmic/man5/apparmor.d.5.html

Quote from the man page:

Rule Qualifiers

There are several rule qualifiers that can be applied to permission rules. Rule qualifiers can modify the rule and/or permissions within the rule.

allow
Specifies that permissions requests that match the rule are allowed. This is the default value for rules and does not need to be specified. Conflicts with the deny qualifier.

audit
Specifies that permissions requests that match the rule should be recorded to the audit log.

deny
Specifies that permissions requests that match the rule should be denied without logging. Can be combined with 'audit' to enable logging. Conflicts with the allow qualifier.
hargut
  • 3,848
  • 6
  • 10
  • Thanks for this answer. I tested it & this gives me a work around to explicitly remove stuff I deny from auditd. I'm going to the leave the question open a while to find out why auditd logs things for which it has no rules. – Nanzikambe Feb 16 '19 at 15:01
0

After looking a bit more into the details there are also ways to configure your requirement on auditd level. There is a list which is named exclude where you can add rules to be filtered out.

As example the following command would exclude any AVC messages:

auditctl -a never,exclude -F msgtype=AVC

In this case the audit event is generated by apparmor and controlled with the loaded apparmor configuration. There no corresponding rule which could be controlled/removed by auditctl on the kernels audit subsystem.

An explicit auditctl filtering rule can be created using the exclude list with corresponding matching rules.

Personally I would prefer the way to not even generate the audit event if it is not needed by configuring apparmor to deny only.

AVC is also called the Access Vector Cache. This cache is used by SELinux/Apparmor to log access decisions and it looks like that this messagetype is by default recorded with auditd and has to be explicitly denied in case the user does not want that. The auditctl man page lists this as example in the exclude section. Further in SELinux there is also a mechanism that writes the AVC logs to disk when auditd is not running.

hargut
  • 3,848
  • 6
  • 10