Centos – Auditd is writing a lot to logs

auditdcentoscentos5redhat

I recently tried to use auditd to find what's creating tmp files on a CentOS 5 x64 OS. I removed the rules:

# auditctl -l
No rules

but there is a lot of writing into auditd logs. If I check the logs using ssh:

# watch ls -la /var/log/audit/

auditd writes 2kb/s. If I check it with samba – it rotates 5MB log file every second. If I check it via ssh and use samba to open a directory – it writes 1 MB each time I open a directory.
I'm comparing that to my CentOS 6 server which doesn't write to logs while I'm checking them via ssh. It only writes when I login/logout via ssh.

I haven't changed configuration.

Update: after server restart the auditd is no longer writing that much data. It still writes something, but it doesn't flood. Here is what it's writing now:

type=CRED_DISP msg=audit(1448603110.552:21): user pid=2708 uid=0 auid=0 msg='PAM: setcred acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'
type=USER_END msg=audit(1448603110.552:22): user pid=2708 uid=0 auid=0 msg='PAM: session close acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'

And there are no rules – auditctl -l shows nothing. Is there anything else than rules that might cause auditd to write in logs?

Best Answer

Did you restart the auditd service? /etc/init.d/auditd restart or service auditd restart

What events are being created in the /var/log/audit/audit.log files?

Related Solutions

Redhat Apache fast-cgi selinux permissions

Running FastCGI your way leaves a big security hole: the PHP interpreter is run as user "httpd" (at least I can't see anything about suexec here).

We have a working setup with SELinux and PHP as FastCGI here at CentOS 6, but it was really tricky to get everything working.

A few tips for the start:

you don't need to reboot to disable/enable selinux - just use the command "setenforce 0" or "setenforce 1" :)
always try to get everything working with SELinux disabled, then enable it and have a look at audit.log

Here we go:

enable suexec
change SELinux type for php.fcgi to httpd_fastcgi_script_exec_t
your FastCGI starter (php.fcgi) should not be writable by the user owning it (otherwise he can tweak many settings and limits). Give it the "immutable" flag: chattr +i php.fcgi

suexec has some trouble with FastCGI, so we have to make it permissive:

yum install policycoreutils-python
semanage permissive -a httpd_suexec_t

Good luck!

Centos – Configure selinux to allow openldap on CentOS 6.4

If you filter the audit logs through audit2allow(1) and audit2why you'll get an approximate idea of what is happening:

#============= slapd_t ==============
allow slapd_t self:capability sys_nice;
allow slapd_t var_log_t:file { write read };
------------------------------------

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1372888328.408:3263): avc:  denied  { sys_nice } for  pid=1492 comm=slapd capability=23  scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:system_r:slapd_t:s0 tclass=capability

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1372888328.424:3264): avc:  denied  { read } for  pid=1493 comm=slapd name=log.0000000001 dev=dm-0 ino=263969 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

Checking labeling

It is unlikely a label restore prevents you from starting a service if SELinux is in permissive mode. Also, why the -F switch?

To know if you have to restore the labeling of a directory or file, first find out what context a file or directory is supposed to have:

# matchpathcon /etc/openldap/
/etc/openldap   system_u:object_r:etc_t:s0

Then list its security context:

# ls -ldZ /etc/openldap/
drwxr-xr-x. root root system_u:object_r:etc_t:s0       /etc/openldap//

In this example, no further action is needed.

With regards to your issue, the problem is not labeling per se, but a missing type enforcement rule, i.e., a rule that allows a labeled process to transition from one confined domain to another, or to read files with an specific label, for example.

Creating an SELinux module

You can try to build a module that allows the slapd_t to perform the operations which appeared in the audit.log. It is probable that you need further adjustments in your code. Use audit2allow, and make for this task. All commands are very well documented in their respective manpages. The process will look roughly like this (after copying the relevant messages into audit.txt):

audit2allow -i audit.txt -m slapd -o slapd.te
make -f /usr/share/selinux/devel/Makefile load

Also, check if a bug report for the SELinux policy regarding this issue already exists.