[PATCH] log all actions by privileged user in bash

[Valdis.Kletnieks at vt.edu]

On Tue, 06 Feb 2007 15:50:20 EST, Steve Grubb said:
> On Tuesday 06 February 2007 15:15, Valdis.Kletnieks at vt.edu wrote:
> > 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.

What happens if the command is 'exec /bin/bash' (or suitable other command
that makes sure that exec_command doesn't return?)  (If your code is currently
logging shell builtins like 'cd', then it's logging at a point in the code
where 'exec' will never come back...)

> 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.

That's assuming they *say* 'vi .bashrc', and don't say 'vi /tmp/innocent' and
then use :r and :w inside vi.  Or just use :sh to get themselves a non-audited
shell.

I'm sorry, but this is just too easy to bypass to count as serious auditing.
It probably *is* a help for answering "Geez George, what *was* that splendiferous
typo that adgered the Oracle server?", but hardly a speed bump for a clued
attacker.

> > 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.

OK, so we're recording something other than "the stream of commands actually
issued by the user", but also doing some things issued *on behalf of* said user.

> > (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.

For both of the above two, I meant that you'd need to document the fact that
(for instance) shell prompts and command editing could result in the logging of
commands never actually directly issued. (Ever been amazed when you tried to do
something like 'awk <magic> | sh -v' and it promptly dutifully traces your
startup script because $BASH_ENV was set? Similar issue here)

> > 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.

I dunno.  I can think of enough ways to bypass it that I have a hard time
convincing myself that it has any hope of making an auditor happy.  Is this
doing a *real* job of auditing any better than just doing this:

readonly HISTFILE=/dev/udp/syslog.server/514



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20070206/9b40eb09/attachment.sig>