Log all shadowing activities.
The logging we'd like to have is information on which user shadowed which user, and when. We could also consider logging when shadowing ends. However that is generally only known to Xvnc so is difficult to keep secure.
(In reply to comment #0) > Log all shadowing activities. Identified shadowing activities: * Shadower attempts to shadow user session * Successfully * Denied * Failed * Shadower disconnected from user session * Shadower-initiated disconnect * User-initiated session exit * Session killed * Session crash
So lets start looking at what kind of logging we already have: * Shadower attempts to shadow user session ✓ Successfully → vsmserver.log ✓ Denied → vsmserver.log ✓ Failed → vsmserver.log * Shadower disconnected from user session ✓ Shadower-initiated disconnect → xinit.log ✓ User-initiated session exit → xinit.log ✓ Session killed → xinit.log ✓ Session crash → xinit.log
Why do we want logs anyway? We've identified two different use cases, both aiming to help the system administrator. * Help troubleshooting program errors * Keep audit trail of user activity Logs for troubleshooting feels like a solved problem - we've verified that we have some kind of logging for all shadowing activities we can think of. More debug logging can be added as seen fit. Collecting an audit trail demands more from our logging: * The shadowing user must not be able to modify or overwrite existing audit records * The audit trail must be available for as long as the administrator requires * It's preferable if the administrator can find the audit trail in a single file
(In reply to comment #4) > > Collecting an audit trail demands more from our logging: > > * The shadowing user must not be able to modify or overwrite existing > audit records > > * The audit trail must be available for as long as the administrator > requires > > * It's preferable if the administrator can find the audit trail in a > single file 1. The obvious approach is to use Linux auditd. Using auditd the above requirements are fulfilled and preferable the common mechanism for audit in linux is used. This would provide a secure way to log audit messages from user space. The administrator enables an application to write auditd events using Linux capabilities, eg with the command `setcap cap_audit_write+eip /opt/thinlinc/libexec/Xvnc`, root user will enable Xvnc to write audit messages. Xvnc itself needs to use libaudit to write the actual events. If Xvnc binary doesn't have the cap_audit_write set, the logging code path results in no-op.
(In reply to comment #5) > (In reply to comment #4) > > > > Collecting an audit trail demands more from our logging: > > > > * The shadowing user must not be able to modify or overwrite existing > > audit records > > > > * The audit trail must be available for as long as the administrator > > requires > > > > * It's preferable if the administrator can find the audit trail in a > > single file > > 1. The obvious approach is to use Linux auditd. Using auditd the above > requirements are fulfilled and preferable the common mechanism for audit in > linux is used. > > This would provide a secure way to log audit messages from user space. The > administrator enables an application to write auditd events using Linux > capabilities, eg with the command `setcap cap_audit_write+eip > /opt/thinlinc/libexec/Xvnc`, root user will enable Xvnc to write audit > messages. Xvnc itself needs to use libaudit to write the actual events. If Xvnc > binary doesn't have the cap_audit_write set, the logging code path results in > no-op. (In reply to comment #4) > Why do we want logs anyway? > > We've identified two different use cases, both aiming to help the > system administrator. > > * Help troubleshooting program errors > > * Keep audit trail of user activity > > Logs for troubleshooting feels like a solved problem - we've > verified that we have some kind of logging for all shadowing > activities we can think of. More debug logging can be added as seen > fit. > > Collecting an audit trail demands more from our logging: > > * The shadowing user must not be able to modify or overwrite existing > audit records > > * The audit trail must be available for as long as the administrator > requires > > * It's preferable if the administrator can find the audit trail in a > single file 2. The other option is to use syslog for logging audit events from Xvnc. This is secure and logs persitency is controlled by administation. However this way of audit trail is kind of old and lacks utilities, functionality and granularity that using auditd provides.
Created attachment 769 [details] Example for auditd logging of application events This little example application will add the following event to the audit log: type=TRUSTED_APP msg=audit(1484813905.091:6074): pid=4544 uid=0 auid=4033 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op="MYAPP:my_application_defined_event" exe="/home/hean01/Development/tests/auditapp" hostname=? addr=? terminal=pts/8 res=success'
(In reply to comment #4) The third option we've discussed is to add some kind of API to VSMServer/VSMAgent that would accept connect/disconnect log entries from Xvnc, and in turn log them to files that the user can't reach.
The missing piece to finish up this bug is to get a more trusted logging of the disconnect event in vsmserver.log, the same place the other entries are.
