Re: [PATCH] log all actions by privileged user in bash

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday 06 February 2007 15:15, Valdis.Kletnieks@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