6

Fail:

# service auditd start
Starting auditd:                                           [FAILED]

Fail: 

# /etc/init.d/auditd start
Starting auditd:                                           [FAILED]

And frustatingly - works:

# bash /etc/init.d/auditd start
Starting auditd:                                           [  OK  ]

I've added something like echo 1 echo 2 in various place in bash /etc/init.d/auditd, so see what path the script takes, to no avail.

The command that is eventually run, and fails is

env -i PATH=/sbin:/usr/sbin:/bin:/usr/bin TERM=xterm /etc/init.d/auditd start

Why does adding bash make it work? Looking for troubleshooting ideas.

Based on Michaels suggestion to use run_init, I could get some meaningful debug out of bash:

# run_init bash -x /etc/init.d/auditd start
[...]
+ /bin/bash -c 'ulimit -S -c 0 >/dev/null 2>&1 ; auditd '
+ '[' 6 -eq 0 ']'
+ failure 'auditd startup'

In /var/log/messages I have

Dec  8 14:54:06 aws-sonar-01 kernel: type=1100 audit(1418050446.762:250): user pid=7196 uid=0 auid=500 ses=6 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="user" exe="/usr/sbin/run_init" hostname=? addr=? terminal=pts/0 res=success'
Dec  8 14:54:06 aws-sonar-01 kernel: type=1101 audit(1418050446.777:251): user pid=7196 uid=0 auid=500 ses=6 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="user" exe="/usr/sbin/run_init" hostname=? addr=? terminal=pts/0 res=success'
Dec  8 14:54:06 aws-sonar-01 kernel: type=1400 audit(1418050446.795:252): avc:  denied  { read } for  pid=7200 comm="auditd" name="audit" dev=xvda1 ino=393285 scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file
Dec  8 14:54:06 aws-sonar-01 kernel: type=1300 audit(1418050446.795:252): arch=c000003e syscall=2 success=no exit=-13 a0=7fa0660a42a0 a1=90800 a2=4000 a3=19 items=0 ppid=7196 pid=7200 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=6 comm="auditd" exe="/sbin/auditd" subj=system_u:system_r:auditd_t:s0 key=(null)
Dec  8 14:54:06 aws-sonar-01 auditd: Could not open dir /var/log/audit (Permission denied)
Dec  8 14:54:06 aws-sonar-01 auditd: The audit daemon is exiting.

I've tried to generate a policy using above as input 

cat messages_above | grep awc | audit2allow -M audit
semodule -i audit.pp

Had a go at selinux policy creation - is this correct? Or missing anything?

semanage permissive -a auditd_t
service auditd start
tail -n 20 messages  |grep auditd | audit2allow -M auditd
semodule -i auditd.pp
semanage permissive -d auditd_t

Still same problem

Jepper
  • 356
  • 1
  • 4
  • 13
  • Two questions. Is root's shell bash? And, what does the shebang at the head of the auditd init script look like? – JasonAzze Dec 05 '14 at 12:11
  • top of auditd is #!/bin/bash. root's shell is bash. It turned out to be selinux. I ran this semanage permissive -a auditd_t and now auditd starts. Have I opened up anything I might regret later? – Jepper Dec 05 '14 at 12:26
  • You've probably messed up the context under which auditd runs, or the context of the log files it writes. – Michael Hampton Dec 05 '14 at 16:03
  • Did you _really_ update your system and run `restorecon` as I previously advised you? It appears that you have not. – Michael Hampton Dec 08 '14 at 15:33
  • Yes. I've rebuilt the instance, but without the puppet module that configured auditd earlier. It's using an AMI that is yum update'd today, but I yum update'd again to be sure. Only two packages were updated. I also ran `restorecon -r -v /` , rebooted, and it still fails. – Jepper Dec 08 '14 at 16:13

3 Answers3

4

On EL (prior to 7) start services on an SELinux-enabled system with run_init to ensure that SELinux contexts and domain transitions are correct.

run_init service auditd start

Or just enable them to start at boot time, which is preferred.

Your log entries indicate that /var/log/audit has the wrong security context. To resolve this:

  1. Update your system. There are new SELinux policy packages which contain many fixes, as well as other updates you are behind on.
  2. Run restorecon -r -v /var/log/audit to fix the security contexts, or better, restorecon -r -v / to relabel the entire system (which fixes a lot of other potential issues as well).
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • That doesn't work. It's enabled `auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off` but it doesn't run at boot time. – Jepper Dec 08 '14 at 11:57
  • 1
    @Jepper You've probably messed up some security contexts, as I mentioned before. First, _update your system_. Then fix the labels for everything: `restorecon -r -v /` Then reboot. – Michael Hampton Dec 08 '14 at 11:59
  • Ok done that. It gets weirder. I've sudu -i then, - `[root@system01 ~]# run_init service auditd start \n Authenticating myuser. \n Password:` – Jepper Dec 08 '14 at 12:17
  • Well, you could always just authenticate. – Michael Hampton Dec 08 '14 at 12:30
  • I'm root when I run run_init. Regardless, if I tap in my password for myuser, `Starting auditd: [FAILED]` – Jepper Dec 08 '14 at 12:56
  • I've updated the question. Seems ulimit fails. – Jepper Dec 08 '14 at 13:53
1
  • invalid options in /etc/init.d/auditd.conf will cause it to fail
  • type ausearch -m DEAMON_END to get which line is in error
chicks
  • 3,639
  • 10
  • 26
  • 36
Fast Eddie Linux
  • 11
  • 1
  • That should be `DAEMON_END`, probably. Regardless, running `/sbin/ausearch ...` solved my problem without finding any `auditd.conf` issues: it reported right away that `"audit.log is not writable by owner"`. Sure enough, `auditd` was refusing to start because `/var/log/audit/audit.log` was read-only. – Urhixidur Nov 23 '17 at 20:11
0

Check the permissions of the /var/log/audit directory. On some distributions they look to be as follows:

0 drw-------.  2 root root     29 Apr 21 13:19 audit

Notice the directory is not executable! A simple

sudo chmod u+x /var/log/audit

Fixed this issue for me

Acyclic Tau
  • 111
  • 1
  • 1
  • 4