Re: [tlug] comand-line recording...

[Bruno Raoult <braoult@example.com>]

On Mon, Sep 28, 2009 at 00:41, Curt Sampson <cjs@example.com> wrote:
> Sorry. I was just trying to help find a good solution to whatever
> your mysterious problem might really be, by trying to understand what
> you really want. If you don't want whatever help and comments people
> are willing to offer, especially when you won't tell them what you're
> looking for in any but a very vague way, I suggest you not post your
> questions.

OK Curt, point taken.

> > Er ... doesn't sudo log every command it executes?
>
> It does, and I'd thought of that. However, I can't seem to get enough
> information out of Bruno about the problem to see if sudo could be
> adapted to his needs, and I wasn't about to waste a lot of time
> speculating about what his problem might or might not be, to see if sudo
> might fit.
>
> Note that sudo, as with the keylogger solution, also does not record the
> same thing that script would.
>
> > Of course, what will happen is people who know they're going to type a
> > lot of commands will sudo su thatuser ....
>
> This can be prevented.

Typing "sudo" for each command is painful. And there are still
numerous cases where
we will loose information (for instance ":sh" in vi, which is very common).

> > Easy solution: auditd provides exec logging with arguments.
>
> This is also not logging the same thing as script would be. Keep in
> mind that it's not going to log the actual command typed in (because
> that's subject to shell processing) and won't log any "command" that's
> performed by the shell itself (such as emptying irretrivably an
> important data file by typing something like ">/http/server/log").

Exact. This looks like a blocking point for me. Another disturbing point is that
we will never know in which directory a command was run.

> > I do not recommend the hacks that are being discussed in other branches of
> > this thread.  If you consider those, you may as well just ask the developers
> > to avoid messing with their history and read the commands from the history
> > files, because any user who wants to circumvent the "auditing" could easily
> > do so.
>
> >From the description we have so far, it's not a problem if users
> circumvent the auditing, so long as they don't do it by writing the log
> file being created.

Yes, the only thing I want to protect is the log file... About history
file, there are many reasons
why we cannot use it:
1) The generic account history file will be shared by all
support/developers, and we would
be unable to find who really typed a given command.
2) The history file (at least for bash) is written on bash exit
3) About (2), we can force a flush after each command (variable
"PROMPT_COMMAND" containing
"history -a"), but it seems to have strange behaviour (as 2 terminals
never show the same history).
I just don't understand the logic of "history -a", so I don't like it ;-)
4) Also, if some people prefer a different shell (for instance running
"tcsh" immediately after logging
on to the generic account, this will be difficult to handle...)

After all the answers, "script" seems then to be my best option... The
output is completely messy, but it
should be usable in case we need it...

Bruno.


--
2 + 2 = 5, for very large values of 2.