11

Short version: How to disable audit messages (dmesg) on a Fedora system?


A Fedora system keeps logging "audit: success" messages in dmesg - in such an extreme way that dmesg has become unusable because it's filled up by these messages (dmesg | grep -v audit is empty). These messages are completely useless as they obviously want to inform the user that some every-day internal process has succeeded (which might be of interest when debugging something, but it's just noise in this case).

Even the command line interface (when switching to a non-X tty with Ctrl + Alt + F2) has become unusable as it's always cluttered with these audit messages, it's impossible to read the output of the commands that are actually run by the user. For example, after entering the username (login), an audit message is spewed out (apparently telling the user that something was formatted/printed successfully):

audit: type=1131 audit(1446913801.945:10129): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

It appears that most of these messages indicate "success", however there are also many audit messages which do not contain this keyword. Running Chromium triggers hundreds of these:

audit: type=1326 audit(1446932349.568:10307): auid=500 uid=500 gid=500 ses=2 pid=1593 comm="chrome" exe="/usr/lib64/chromium/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7f9a1d0a34f4 code=0x50000

Other messages include:

audit: type=1131 audit(1446934361.948:10327): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

audit: type=1103 audit(1446926401.821:10253): pid=28148 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=p am_env,pam_unix acct="user" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'

Generally, the majority of recent audit messages (at the time of writing) contains the keyword "NetworkManager" or "chrome".

How can these messages be disabled completely?


Additional points:

  • In case anyone might be thinking "you should read and analyze these audit messages, not disable them, they could be important", no they are not important, they're almost exclusively "success" messages. Nobody needs to be told that something which is supposed to work did in fact work. However, if one actually significant message was being logged, it would never be noticed in the storm of thousands of insignificant messages. In any case, no audit logging is wanted on this particular system (it's running in a controlled environment anyway).
  • Clearly, something must be very misconfigured on this system. However, it was once a default Fedora installation which has been upgraded whenever a new release came out. Maybe it's just a simple setting that has to be changed, but as it did not happen changing the system configuration manually (on purpose), this stackexchange.com question will hopefully help others who happen to have gotten their system in the same state.
  • It's now a Fedora 22 system, running Linux 4.0.6 (systemd 219).
  • It's a standard Fedora desktop installation, currently running KDE.
  • SELinux is disabled (/etc/selinux/config is set to "disabled").

Update: After upgrading to Fedora 23 (kernel 4.2.5, systemd 222), there are fewer audit messages than before.

  • Instead of disabling audit, which disables writing audit messages to logs that you can view with audit2allow, did you consider simply modifying the kernel.printk value that is relevant to printing kernel messages to the console? On Fedora by default it is "7 4 1 7", a more sensible value is "3 4 1 7". – Bob May 10 '17 at 14:58
12

Firstly, on fedora, both auditd and auditctl come from the same package (unconfusingly named audit). So if you don't have auditctl, something else is wrong. Try this:

rpm -ql audit |grep ctl

If that gives you nothing, then you do not have the audoit package installed at all.

Secondly, the first "human" language line in the grub.cfg file you mentioned says "DO NOT EDIT" on my system. This is a clue that any manual changes to the file can be lost.

The correct place to edit the grub config on a fedora/redhat system is the one file you specifically suggested as not being necessary to change (/etc/default/grub). In reality, this is the only "safe" way to make the proposed change and survive kernel upgrades. This is becuase it is used as part of the source configuration during kernel upgrades, to regenerate a working grub.cfg. Look up the grub2-mkconfig command (and it's friends). Details here: https://fedoraproject.org/wiki/GRUB_2

Your answer is not wrong, but I found it a little confusing. I hate the grub command line, and IMHO anyone who is likely to miss adding a whitespace char on a kernel command line would probably not thank any one for being lead down that road. Still, some poeple like to learn the hard way I know.

All commands below need to be run as root (which is in and of itself a dangerous thing to suggest).

For a running system:

auditctl -e 0

If you cannot find auditctl, check your PATH and also consider:

dnf install audit

This should at least reduce if not disable the messages until such a time as you can reboot.

To persist beyond reboots, edit /etc/default/grub and change the GRUB_CMDLINE_LINUX line to add "audit=0" to the end, then use grub2-mkconfig to regenerate the grub.cfg. This final step also puts a layer of validation between your change, and the running system.

  • Thanks for pointing out that /etc/default/grub and grub2-mkconfig should be used. I've added a correction to my answer. – basic6 Nov 29 '15 at 13:53
6

You can quickly disable audit temporarily with

sudo auditctl -e 0

and temporarily remove all the rules with

sudo auditctl -D

For future boots you could try disabling its start with

 sudo systemctl disable auditd
3

There is no auditd service that could be disabled while the system is running, but it turns out that adding the boot option audit=0 seems to disable all of these messages. The system is usable again, even on command line without X running.

This option can be set temporarily (the change will not survive a reboot):

  1. When the Grub boot menu appears (right after turning the power on), hit e to edit the boot parameters. This will show a huge text box.
  2. Scroll down to the line that starts with "linux". Hit the End key to move the cursor to the end of the line.
  3. Enter a whitespace character so that you don't break the last option, then append audit=0. For example ... LANG=en_US.UTF-8 audit=0 (not ...UTF-8audit=0, obviously).
  4. Be careful not to change anything else. If you've accidentally modified some other option, fix it or reboot and start over.
  5. Hit F10 to boot the system.

Of course, this change will only be in effect while the system is running. The audit flood will come back after a reboot. To make this change permanent, the boot configuration has to be changed permanently. On Fedora, it should be enough to simply modify /boot/grub2/grub.cfg because when a new kernel is installed (system update), grubby should copy the options of the latest kernel to the newly installed kernel. This means, audit=0 has to be appended to the first linux line (first menuentry section) in this file. It shouldn't be necessary to change /etc/default/grub.
Correction: Actually, the correct and most reliable approach is to edit /etc/default/grub and regenerate the Grub config using grub2-mkconfig -o /boot/grub2/grub.cfg, thanks KnightLordAndMaster for pointing this out.


Additional note on audit logs in log files:

As a side note, the following line should prevent audit logs from ending up in log files, but they would still clutter dmesg and the console, so this is not a solution in itself. This line would be put as first rule in /etc/rsyslog.conf:

...
#### RULES ####

# no audit
:programname, isequal, "audit" ~

...

This now results in the following warning:

 rsyslogd[xxxx]: warning: ~ action is deprecated, consider using the 'stop' statement instead [v8.35.0 try http://www.rsyslog.com/e/2307]

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.