fragen stichworte

Centos 6.5 auditd kann nicht mit service oder /etc/init.d/audit start gestartet werden

Fehler:

# service auditd start
Starting auditd:                                           [FAILED]

Fehler:

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

Und frustierend funktioniert:

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

Ich habe in bash/etc/init.d/auditd an verschiedenen Stellen etwas wie Echo 1 Echo 2 hinzugefügt. Sehen Sie also, welchen Pfad das Skript einnimmt, ohne Erfolg.

Der Befehl, der schließlich ausgeführt wird und fehlschlägt, ist

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

Warum funktioniert das Hinzufügen von bash? Suche nach Ideen zur Problembehandlung.

Basierend auf Michaels Vorschlag, run_init zu verwenden, könnte ich aus bash etwas aussagekräftiges Debugging erhalten:

# 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 habe ich

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.

Ich habe versucht, eine Richtlinie zu generieren, die oben als Eingabe

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

Wollte man die Selinux-Politikerstellung - ist das richtig? Oder etwas vermisst?

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

Immer noch dasselbe Problem

antworten

Starten Sie bei EL (vor 7) Dienste auf einem SELinux-fähigen System mit run_init, um sicherzustellen, dass die SELinux-Kontexte und Domänenübergänge korrekt sind.

run_init service auditd start

Oder lassen Sie sie einfach zum Startzeitpunkt starten, was bevorzugt wird.


Ihre Protokolleinträge weisen darauf hin, dass /var/log/audit den falschen Sicherheitskontext hat. Um dieses Problem zu beheben:

  1. Aktualisieren Sie Ihr System. Es gibt neue SELinux-Richtlinienpakete, die viele Korrekturen sowie andere Aktualisierungen enthalten, hinter denen Sie stehen.
  2. Führen Sie restorecon -r -v/var/log/audit aus, um die Sicherheitskontexte zu beheben, oder besser, restorecon -r -v/, um das gesamte System neu zu kennzeichnen (was auch viele andere potenzielle Probleme behebt).
  • Ungültige Optionen in /etc/init.d/auditd.conf führen dazu, dass es fehlschlägt
  • Geben Sie ausearch -m DEAMON_END ein, um zu ermitteln, welche Zeile fehlerhaft ist

Überprüfen Sie die Berechtigungen des Verzeichnisses/var/log/audit. Auf einigen Distributionen sehen sie wie folgt aus:

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

Beachten Sie, dass das Verzeichnis nicht ausführbar ist! Ein einfaches

sudo chmod u + x/var/log/audit

Dieser Fehler wurde für mich behoben