2

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.

Improve this question
5
  • Have you ensured the auditd daemon is running and there's a rule in place to log the restricted action?
    – dawud
    Oct 10, 2013 at 16:48
  • Check auditd is running, if not look in /var/log/messages
    – user9517
    Oct 10, 2013 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, 2013 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, 2013 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.
    – Michael Hampton
    Oct 10, 2013 at 17:20

3 Answers 3

Reset to default
7

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
Improve this answer
1
  • Genius!, in my case selinux was not showing violations from tclass unix_dgram_socket
    – muttonUp
    Jan 4, 2019 at 14:10
4

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.

Improve this answer
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .