terminal logging and handler logic

[djschny]

Is your feature request related to a problem? Please describe.

I will describe the use cases here, some are a problem, some are not.

• Abuse - learners may try to use the system/platform for malicious or abusive behavior. For example using resources for bitcoin mining, sending spam emails, DOS to sites, or general hacking into a system trying to hide their entry behind other systems.
• Learner Insight - as a person creating workshop/lab content, it can help to know what people are doing when in the lab. For example, how many commands did they type and at what time in the lab? Did they get errors often, did they try for help, try to do things other than what the lab instructions state, etc. By logging terminal output (with metadata) it would allow that insight to be available to the workshop author(s).

Describe the solution you'd like

The thought was a few things:

• One could optionally enable terminal logging in a workshop definition. It would then collect the terminal input/output and store it in educates cluster.
• Optionally a person could configure a "sink" for the terminal logging to go to (Object Store, Google Drive folder, SFTP, Queue, Webhook, etc) for longer term storage/analysis
• Option to specify a container or script that could be registered as a "handler" to process the logging events live in a streaming manner and then take actions accordingly. For example it could be given the metadata about the stream of logging and if malicious behavior is detected the handler could delete the workshop sessions, or take other actions.

Describe alternatives you've considered

Providing a cronjob or other streaming agent installed in the workshop tries to get at the .bash_history or other files and ship them off to somewhere else for processing

Additional information

No response

[GrahamDumpleton]

For first stage of exploring what can be done, would suggest that build on existing implementation of frontend/backend for terminals that actually allows multiple browser windows on the same terminal session.

One issue with this existing functionality is that if the viewport sizes for the terminal are different then the second browser window will force a terminal size change on server side for process attached to pty, thus affecting the first browser. It is because of this and to flag first user that something strange is going on, that "HIJACKED" message is shown on first browser terminal window to indicate was taken over.

For purpose of exploring capturing terminal data in better way idea is that could work out how to have a read only viewer using this mechanism where second browser doesn't actually force a resize of process attached to pty, but instead resizes browser window to accomodate the existing terminal size. No terminal resizing would be triggered from second browser and instead scrollbar would show around the frame instead if was made smaller, that or could see if could somehow use proportional scaling of view so maintain original col/rows of terminal.

The idea is that one could add access to this view of terminals to special admin pages in training portal, thus allowing a trainer to view anyones terminals if needed without interfering with the terminal size (as would occur now if admin visits users session dashboard when URL is known), with by default no input accepted from second browser, although could have a toggle to permit entry so trainer could run stuff through users terminal.

This system would make use of existing web socket capability exposed by session dashboard. In adding this proper read only like view, can then see if we can make use of this to pull input/output into a separate monitoring service rather than a browser for capture, later replay, or searches for malicious commands.

[djschny]

Can we bump up the priority of this as it would help workshop abuse scenarios.

cc @billkable

[GrahamDumpleton]

Since is not easy to capture individual commands entered at the terminal, since is stream of messages for individual characters, option have been thinking of is to capture the stream of messages that get sent to front end to render the terminal. These are already being held internal to backend process within a sliding window memory buffer to allow replay to front end when a window is refreshed, so that visual state of terminal can be redrawn. So is just necessary to write them out to a file at the same time and work out a way then to get them out of the container, or stream them live to a remote service. This would allow later offline replay of a session, although right now it doesn't have time stamps so one couldn't replay them in orderly manner and not have a mess when it fires up a visual text editor and wipes out the displayed terminal buffer. Anyway, will give it some more thought.