[PATCH] log all actions by privileged user in bash
Steve Grubb
sgrubb at redhat.com
Tue Feb 6 20:50:20 UTC 2007
On Tuesday 06 February 2007 15:15, Valdis.Kletnieks at vt.edu wrote:
> On Sun, 04 Feb 2007 19:54:25 EST, Steve Grubb said:
> > Hi,
> >
> > execute_command (current_command);
> > +#if defined (AUDIT_SHELL)
> > + {
> > + extern char *shell_input_line;
> > + audit (shell_input_line, last_command_exit_value);
> > + }
> > +#endif
>
> Umm.. audit *before* exec, in case the command is 'nuke_audit --force'? ;)
There are security targets that say that they want the success/fail
indication. So, to satisfy that, I have to use post-command auditing. If they
did nuke the audit system, that would get recorded. They either do
auditctl -e 0 which results in an event, or they killall -s KILL auditd,
which that produces something in syslog.
> It's not clear that this can't be bypassed by (for instance), doing
> something evil like this
auditing root wasn't intended to be bullet proof. If you do not trust the
admin, the audit system will not save you. They could "rpm -e audit"
or "ifdown eth0" and stop remote logging. SE Linux might help keep a
potentially bad admin between the ditches. But even with SE Linux they could
easily do rpm -e audit.
> PS1="Normal prompt except for `exec_evilness_here`"
Setting this should get recorded, and edit of .bashrc should get recorded if
they put it there. They could also edit a script, run the script, delete the
script as well.
> Looks like the shell completion could be fun too:
>
> edit-and-execute-command (C-xC-e)
> Invoke an editor on the current command line, and execute
> the result as shell commands. Bash attempts to invoke $FCEDIT,
> $EDITOR, and emacs as the editor, in that order.
I'm thinking the resulting command gets recorded.
> (I haven't checked the source - the execute_command() function may in fact
> get called for these cases. If so, you probably need to document that some
> output may be created even if the user isn't actually submitting a command,
> so care needs to be used when correlating to actual terminal activity).
I haven't seen any case where something hit the logs that wasn't supposed to
be there.
> And given that 'cat > /tmp/evil; chmod +x /tmp/evil; /tmp/evil' and
> 'evilscript | /bin/sh' will work, about all this audit trail will show is
> that *something* unusual happened - an attacker wouldn't have much trouble
> disguising exactly *what* was done....
True. I think that's all you *can* do. At the same time, I want to harden it
if anyone sees a weakness that can be fixed.
-Steve
More information about the Linux-audit
mailing list