Re: Using script(1) to log all user sessions

["Ángel González" <ingenit@zoho.com>]

On 25/04/14 10:21, Jesper Dahl Nyerup wrote:
> Hi list,
>
> We're toying with the idea of using script(1) to log all user sessions
> towards a collection of systems, as one in a number of metheds to aid
> debugging, education and auditing.
>
> In order to do so, I have a couple of questions regarding a few
> extensions we're considering to implement.
>
> Firstly, script(1) is clearly and sanely designed to be invoked from the
> command line to record a limited portion of a user's session. In order
> for the user to have the logging started without manual invocation, it
> may come in handy to support config files, to supply configurable
> default values for some of the concepts normally passed in the
> environment or as command line arguments.

You can start it from a script acting as the user shell, through sshd 
config or one of the shell init scripts. As you already need to start 
script somehow, those defaults could be passed there, too (although I 
don't see a problem with supporting config files either).


> Secondly, we're considering to add functionality for script(1) to
> transmit the session transcript over the network to a collection daemon,
> to be able to store transcripts from multiple machines on one or more
> central systems.
>
> This could involve:
>
> 1. Adding a daemon next to script(1) and scriptreplay(1), eg.
> scriptcollect(1), to be in the receiving end of the traffic, optionally
> handling the timing functionality, and finally storing data in the same
> manner script(1) would.

I'm unsure about this bit. It may be needed. Perhaps a transfer after 
the session finishes also works.


> 2. Optionally linking against some crypto library to avoid putting
> users' console data on the wire in clear text.

Following unix philosophy, I would try to avoid reinventing crypto into 
the program, attempting instead to solve the issue by eg. using sftp to 
transfer the files and/or gpg to encrypt the data.



PS: I expect you are properly warning your users about the fascist-level 
logging done on your systems.