Re: [PATCH] log all actions by privileged user in bash
On Tuesday 06 February 2007 15:15, Valdis.Kletnieks(a)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