3

Hello I've been tasked with fixing up a auditd policy but it's on a server that's actively being used and the policy installed was set immutable. I've tried searching and everyone recommends rebooting to escape immutable mode… But is there really no way to code up something that, as root, removes immutable mode without a reboot? I find it pretty amazing nobody seems to have attempted to do this already.

John Musbach
  • 31
  • 1
  • 1
  • 2
  • 2
    Well, in all fairness the man page for `auditctl` does say `The configuration can only be changed by rebooting the machine.` – Matthew Ife Apr 02 '14 at 17:27
  • Yeah, but isn't there some way to edit the config wherever it's in memory? I'm sure there's a way to hack around the reboot requirement and I'm sure such a solution would be enjoyed not just by me but any sysadmin who needs to update immutable auditd policies on a production server. The current "solution" to modifying immutable policies does not seem like it was done with production environments in mind. – John Musbach Apr 02 '14 at 17:33
  • 1
    The whole point of the immutable flag is that you *need* a reboot to remove it. That's the purpose of it. – MichelZ Apr 02 '14 at 17:36
  • @JohnMusbach It is a bit in kernel memory, I wouldn't want to go tweaking something in there.. – Matthew Ife Apr 02 '14 at 17:47

1 Answers1

3

Charged this windmill many times.
Proper security posture requires that the rules be set to immutable (-e 2), to prevent "bad guy" from changing it and hiding his "bas activities" from the sys admins.
The "bad guys," if they exist, will attempt to change the auditd rules far more often than the system administrators will need to legitimately change them. That is why the immutable flag does not allow changes.

As far as the reboots go, this is a big issue with SAs, vs. Developers vs. Users. I have fought this fight far too often -- from all 3 perspectives.
The proper answer is: SOMETIMES the server needs to be rebooted!!
You need to have pre-established maintenance windows to exactly this kind of thing. If there is no maintenance, then don't take the outage.

If the users/developers/managers don't like this answer, they can wait until it crashes and then no one knows how long it will take to repair it.

Generally speaking, if everyone agrees on a down time, you can make the changes. You may hear a lot of grumbling. That is the nature of a Sys Ad's job.

BTW: I've tried to set -e 1 in my audit.rules file, load it, then run auditctl -e 2, but this does not work. :'(

Scottie H
  • 227
  • 2
  • 9
  • 1
    I agree and glad I found this. Had a problem with two exact rules on two servers with the same OS version and packages, where one server would not show the rule. Then I noticed the "immutable" message and after rebooting the rules matched. – aseq Dec 18 '21 at 06:23