[sudo-users] sudoreplay logs from syslog-server

[Patrick Spinler]

On 09/07/2011 10:30 AM, JR Aquino wrote:
> 
> Pat, I have looked into this as we are also interested in centralization, and as I have a great deal of experience with custom syslog solutions...
> 
> Since Sudo is stepping in with its own vtty, it stores the data in a binary format. The record of events are not merely ascii text, but rather, the recording of the exact keystrokes including the speed at which they were typed, and backspace/delete sequences.  I do not believe it is possible to articulate this data in its current form into ascii.
> 
> What I have settled on, is the idea that the files can be monitored by a daemon, and transferred to a central location after each one is fully written.  They can be transferred into a similar directory hierarchy to syslog-ng, whereby the sub-domain/servername/dated-filename-sudoio.log would live.
> 
> From there sudoreplay can be used on the central server itself to review questionable time periods similar to the inspection of video surveillance tapes.
> 
> I am interested in assisting in any effort to help centralize Sudo's IO logs, though I am not confident that it will / can be done with syslog.
> 

There are several useful standards for encoding binary data into
printable ascii, e.g. mime64, uuencode, etc.

Instead of or in addition to immediately writing the tty streams to a
file, buffer them to a small level (64 bytes?); encode the buffer into
printable ascii; tag the line with a human readable prefix / suffix
including a session identifier, sequence number, and checksum, and drop
it into syslog.

Include a session start syslog message with the appropriate session id,
user id, source tty and other useful info, and a final syslog message as
a session close with the number of syslog records written, a master
checksum, and the like.

Possibly include periodic session snapshot records, if a useful concept
of a snapshot exists (unlikely, but ???)

Then, on the other side of things, enable sudoreply to scan a file for a
specific session id,  check it for validity (e.g. any missing records),
read it in and decode it, report an error if it's corrupted, and replay
whatever it can.

For installations where a full, uncorrupted log is critical, users can
configure syslog to use tcp and get reliable delivery.

-- Pat