I'm trying to configure a set of lockdown rules. My approach is to start with a restricted user, and use audit2allow messages to selective add permissions. My problem is that I don't see the expected denial messages in /var/log/audit/audit.log.

For my test, I'm logged in to the box via SSH as a restricted user. I try to cat /etc/init.d/sshd. With SELinux enforcing, I see a "permission denied" error in the shell. With SELinux in permissive mode, I can run cat without an issue. But in either case, I don't see denial messages in the log.

Update: I do see denied messages when trying to mount a partition, but still not for cat.

  • Have you ensured the auditd daemon is running and there's a rule in place to log the restricted action?
    – dawud
    Oct 10 '13 at 16:48
  • Check auditd is running, if not look in /var/log/messages
    – user9517
    Oct 10 '13 at 16:48
  • auditd is running: ps aux | grep auditd root 1829 0.0 0.0 27636 816 ? S<sl 09:25 0:00 auditd
    – lairtech
    Oct 10 '13 at 17:04
  • @dawud: I didn't think I needed an explicit log rule. I thought SELinux denial are logged by default.
    – lairtech
    Oct 10 '13 at 17:06
  • 1
    They are logged by default. Please post the results of your support case with Red Hat that you opened prior to asking. Oct 10 '13 at 17:20

Looks like the default selinux policy has some don't audit rules, which were catching this case. Once I disabled don't audit, I see the expected behavior.

semodule --disable_dontaudit --build
  • Genius!, in my case selinux was not showing violations from tclass unix_dgram_socket
    – muttonUp
    Jan 4 '19 at 14:10

Try ausearch -ts today -m avc -m user_avc -m selinux_err and see what comes up.

You are possibly running into a constraint violation or an invalid context generation. selinux_err will pick those up.

Also some messages (in particular userspace object managers) may only log into dmesg. So try looking there too.


Edge case - if you rm /var/log/audit/audit.log, auditd is not smart enough to create a new file. If you touch /var/log/audit/audit.log, auditd is not smart enough to write to the new file you just created. You have to restart the auditd service to get your logging working again.

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.