dmesg filled with audits every minute from cron

Question

My dmesg is filled with output of like the following, starting from a couple of seconds after booth and continuing indefinitely:

[ 3155.216230] type=1006 audit(1393236841.859:85): pid=4206 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=84 res=1
[ 3214.742935] type=1006 audit(1393236901.406:86): pid=4227 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=85 res=1
[ 3274.960017] type=1006 audit(1393236961.646:87): pid=4245 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=86 res=1
[ 3335.143342] type=1006 audit(1393237021.853:88): pid=4266 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=87 res=1
[ 3394.290920] type=1006 audit(1393237081.024:89): pid=4325 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=88 res=1
[ 3454.269891] type=1006 audit(1393237141.024:90): pid=4344 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=89 res=1
[ 3514.802667] type=1006 audit(1393237201.575:91): pid=4424 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=90 res=1
[ 3574.320552] type=1006 audit(1393237261.119:92): pid=4441 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=91 res=1
[ 3634.364982] type=1006 audit(1393237321.187:93): pid=4498 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=92 res=1
[ 3694.503761] type=1006 audit(1393237381.347:94): pid=4559 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=93 res=1

This is caused in part by cron. If the root crontab includes * * * * * echo test, the audits appear once a minute. If it is empty, no audits appear.

Why does this happen? How can I stop it?

Edit: I'm running an updated Arch Linux. Trying to find the process that causes the audits:

$ systemctl -a | grep audit -i
auditd.service     not-found inactive dead      auditd.service

@adrianmcmenamin It appears with all commands I've tried. Not using cronie is not an option. — Anna, Feb 24 '14 at 11:42

ek9 · Accepted Answer · 2014-02-25T19:09:47.160

These are caused due to SELinux permission denials logged by the audit service. Your user probably needs special SELinux permission to run cron.

Or if cron runs successfully then SELinux is set to permissive and only prints it as information. On systems with SELinux the option is configured in /etc/selinux/config:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

After you said its not SELinux as you dont have it installed, I have found this:

The audit messages are related to reworking of the audit subsystem in linux 3.13 (and possibly 3.12.9). They certainly don't indicate a breakin. I don't know how to disable them currently (OTOH, more information can't hurt). The only downside is that there are frequent disk writes which can wear SSDs. So, here is a modification to syslog-ng.conf to make syslog put these messages to memory:

destination d_audit { file("/tmp/log/kernel-audit.log"); };
filter f_kernel { facility(kern) and not filter(f_iptables) and not filter(f_audit); };
filter f_audit { match("type=" value("MESSAGE")) and match("audit" value("MESSAGE")) and      match("uid=" value("MESSAGE")); };
log { source(src); filter(f_audit); destination(d_audit); };

Of course, this assumes that /tmp/log exists before syslog-ng starts. Those using only journald... are out of luck smile.

I guess you should try to follow https://bbs.archlinux.org/viewtopic.php?id=171103 to see if anything comes up over there. Rest assured, it seems to be safe to ignore.

As I am also running archlinux I have checked my dmesg but I do not have these messages. I could try to suggest removing audit package if you don't need it (I do not have it nor do I know it's purpose, but I also do not get these messages).

pacman -R audit

Thank you. However, SELinux is not installed on my system. I'm running Arch Linux in case it matters. — Anna, Feb 25 '14 at 07:51
I am running archlinux too, I have found something on forums, updating main post in a minute. — ek9, Feb 25 '14 at 19:05
Thank you for pointing me to that thread! They seem to have the same problem as I do. I don't have audit installed either. I'll follow the thread and see what happens. — Anna, Feb 26 '14 at 10:03

score 0 · Answer 2 · edited Sep 16 '15 at 10:39

0

Try to add audit=0 in the kernel line.

This is a systemd gift, known limitation of the in-kernel audit code, and is being tracked here.

Needs to be fixed in the kernel.

Reference by Lennart Poettering

edited Sep 16 '15 at 10:39

Kevdog777

3,194
18
43
64

answered Sep 16 '15 at 09:29

Andabata

1

score -2 · Answer 3 · edited Apr 07 '15 at 19:44

-2

Code is not normally run within a cron. Create a file echo.cron, set mode to 0500, and then use this in your crontab:

* * * * * echo.cron

edited Apr 07 '15 at 19:44

Michael Mrozek

91,316
38
238
232

answered Apr 07 '15 at 19:01

David

1

What makes you think that the name of a user-written script will behave any differently than any other command? (For that matter, what do you mean by “Code is not normally run within a cron”? People put long, complicated command lines into crontab all the time. And `echo test` is not code. If she had said `write(1, "test\n", 5);`, that would be code.) Besides, she says (in a comment) “It appears with all commands I've tried.” – G-Man Says 'Reinstate Monica' Apr 07 '15 at 19:14

dmesg filled with audits every minute from cron

3 Answers3

Linked