2009-02-18 08:20 AEST by Arthur Barrett - Enhancement: Improve CVSNT audit of security.

Currently CVSNT does not audit security events, such as failed logins.  This is 
instead assumed to be a requirement fulfilled by the operating system (eg: if 
an SSPI or PSERVER login fails on a CVSNT server on Windows 2003 the Event Log 
will show the details of the failure).

However some customers want the CVSNT audit to be comprehensive, and some CVSNT 
operations do not generate an operating system audit event (eg: pserver with 
SystemAuth disabled).

An example list provided from a prospect follows:
• All successful and unsuccessful login attempts
• All logoff's
• Login attempts using invalid passwords
• Additions, deletions and modifications to user accounts/privileges
• Users switching IDs during an online session
• Attempts to perform unauthorized functions
• Activity performed by privileged accounts
• Modifications to system settings (parameters)
• Access to restricted data
• Additions, deletions and modifications to security/audit log parameters

In particular:
* CVSNT currently does not audit pserver, sspi, sserver, gserver failures
* CVSNT on windows currently does not audit changes to settings via control 
panel 
* Failsafe auditing of registry changes on windows or failsafe auditing of 
changes to /etc/cvsnt/PServer is not possible, however 
  + CVSNT could 'encrypt' a copy of the critical settings (particularly audit 
settings) and store them separately and re-encrypt the plain ascii settings 
each time and compare to the encrypted copies - if they are different (or there 
is no pre-existing encrypted copy) then it is an auditable event
  + CVSNT could audit the current critical settings each time (eg: in 
sessionlog, or in a different table).
* The protocols only communicate the 'logon' user id, not the 'real' user id.  
Any security here could be compromised by a malicious client (or any non-CVSNT 
client) however it would provide the server something addition to log ('os user 
id' in sessionlog).
* The protocols could communicate the protocol certificate - if the certificate 
is not 'March Hare Software ltd' and/or not valid then it could be denied (ie: 
deny not merely non-CVSNT clients but non-March Hare CVSNT clients, in a 
simple/basic attempt to prevent malicious clients).

2010-04-30 08:59 AEST by Arthur Barrett - With CVSNT 2.8.x (Suite 2009/2010) this is more feasible because the audit trigger is preinit'ed early 
(before clients connect) so auditing invalid passwords etc is possible.

Note that "Attempts to perform unauthorized functions" includes auditing ACL failures - eg: commit a 
file without write permission.

Provisionally targeting this feature for CVS Suite 2010 (2.8.02) - currently scheduled for preview release 
before June 30, 2010:
* new 'errorreport' trigger - needs to pass similar params as to create a sessionlog
* implement 'errorreport' trigger in audit plugin
* new audit table 'errorreportlog' with:
  + id (primary key)
  + sessionid (foreign key to sessionlog)
  + errormessage
   (note: if sessionlog has not been created yet [check using global var] then need to create it too)
* other alert options?  eg: email, syslog, eventlog? (see bug 4959)
* if server is true - call run_trigger(errorreport) from error() in error.cpp

2020-05-08 11:21 AEST by Arthur Barrett - I think we should consider retargeting this for the 2.8.01 refresh as per bug Bug 7429

• All successful and unsuccessful login attempts
• Login attempts using invalid passwords
• Additions, deletions and modifications to user accounts/privileges (chacl)
• Attempts to perform unauthorized functions
* in SessionLog include critical parameters (SystemAuth, ACLCompat, Plugins)
* SessionLog should include the realuser if available
* new clients should send "am-i-signed" and "signer-name" and "signer-authority", server can log this

See the previous description of work to get the errorlog/sessionerror functioning.