6

We recently implemented some auditd rules in response to an external security audit. My colleague offered some input on them and suggested adding -f 2 to /etc/audit.rules. I can't think of an instance when I would want to induce a kernel panic outside of testing.

Can anyone suggest real-world, production situations that would warrant this?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
theillien
  • 1,308
  • 4
  • 15
  • 34
  • 1
    In my server perimeter time is critical. If a server starts drifting too much or behaving eratic due to hardware clock going crazy or PTP synchronization failing, i prefer the server to crash, than to continue its critical activity with wrong time. If for example `/etc/password` is modified i would also prefer a kernel crash, than letting my server working with a potential security breach. This introduce a kind of DOS, but sometime you have to chose according how you can manage the risk. – netmonk Sep 15 '15 at 09:25

1 Answers1

3

auditctl -f 2 causes a panic, essentially, when the audit mechanism is unable to operate properly.

There are high-security environments where proper access controls and full logging are critical, and if any logging fails, the system must be stopped (at that point, the technician on duty has already been paged). Financial transactions tend to be like that. auditctl -f 2 is for such environments.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • Thanks. The financial industry is what I was thinking about as well as, perhaps, some government systems. I provided the section from the man page to my colleague as well with italics emphasizing the portion stating that it is for error handling rather than being triggered by a logged event. – theillien Sep 16 '15 at 22:32