You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was testing a subset of these rules along with what my $dayjob currently has. Something I noticed testing on PopOS/Ubuntu was that with the DAC modifications, they wouldn't catch anything, with at least bash (didn't test any other shells). I'm fairly new to auditd so I'm thinking it just a bash issue, but after I put the path to log some of the DAC modifications then it started logging. Am I missing the purpose of the DAC rule section or is this just a side effect of bash?
Evaluation goes top-to-bottom (auditcl -l) so maybe you have a matching rule before those could be triggered. -S chown would catch a syscall called chown and this is what probably can't reach the mentioned line.
In contrast the -F path=/usr/bin/chown -F perm=x is watching for the execution of that particular file.
So there is a tiny, little probability that chown or sg. else is broken on your system but imho there is a much higher probability some rules are matching to the same events earlier. Don't forget to check the auids also!
I was testing a subset of these rules along with what my $dayjob currently has. Something I noticed testing on PopOS/Ubuntu was that with the DAC modifications, they wouldn't catch anything, with at least bash (didn't test any other shells). I'm fairly new to auditd so I'm thinking it just a bash issue, but after I put the path to log some of the DAC modifications then it started logging. Am I missing the purpose of the DAC rule section or is this just a side effect of bash?
Example:
wouldn't log anything but
-a always,exit -F path=/usr/bin/chown -F perm=x -F auid>=1000 -F auid!=-1 -F key=perm_mod
does.
The text was updated successfully, but these errors were encountered: