www.cendio.com
Bug 97 - Shadowing doesn't log disconnect to vsmserver.log
: Shadowing doesn't log disconnect to vsmserver.log
Status: NEW
: ThinLinc
VSM Server
: pre-1.0
: PC Unknown
: P2 Enhancement
: MediumPrio
Assigned To:
:
:
:
: 98
  Show dependency treegraph
 
Reported: 2002-08-16 14:03 by
Modified: 2017-01-31 11:32 (History)


Attachments
Example for auditd logging of application events (673 bytes, text/x-csrc)
2017-01-19 09:20, Henrik Andersson
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2002-08-16 14:03:12
Log all shadowing activities.
------- Comment #1 From cendio 2016-12-12 11:07:40 -------
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.
------- Comment #2 From cendio 2017-01-17 14:47:27 -------
(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
------- Comment #3 From cendio 2017-01-17 16:03:37 -------
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
------- Comment #4 From cendio 2017-01-17 16:52:35 -------
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
------- Comment #5 From cendio 2017-01-19 09:12:25 -------
(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.
------- Comment #6 From cendio 2017-01-19 09:15:33 -------
(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.
------- Comment #7 From cendio 2017-01-19 09:20:21 -------
Created an attachment (id=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'
------- Comment #8 From cendio 2017-01-19 10:26:55 -------
(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.
------- Comment #9 From cendio 2017-01-31 11:32:43 -------
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.