support using pam_audit.so in "account" stack

[Leigh Purdie]

On Mon, 2005-02-21 at 18:13 -0800, Casey Schaufler wrote:
> --- Klaus Weidner <klaus at atsec.com> wrote:
> > On Mon, Feb 21, 2005 at 02:44:10PM -0800, Casey
> > Schaufler wrote:
> > > --- Klaus Weidner <klaus at atsec.com> wrote:
> > > > I'm not aware of an explicit CAPP requirement
> > for
> > > > logout messages, so I'd
> > > > consider that to be a "nice to have" feature.
> > > 
> > > You need a logout message. Really.
> > 
> > Can you point to a specific requirement in CAPP
> > related to that?
> 
> Nope. On the other hand, I cannot point to
> a system that has been successfully evaluated
> that does not do this.

I'd also recommend including logout information - regardless of the fact
that non-interactive access may still continue (eg:
nohup /path/to/blah), it is pretty important for some organisations to
be able to determine a users interactive login and logout times.

Sure, this information can be grabbed indirectly from exec* events, or
even file-open data, but the volume of audit data that results from
enabling such events may not be justifiable in the context of a
workstation, where the goal may be just to provide 'supporting evidence'
of a problem/compromise on a server system.

For example:
On a server system, administrators have decided to enable file auditing
for the /path/to/secretstuff directory.

Audit log data indicates that the user 'joe_bloggs' attempted to access
a file /path/to/secretstuff/classified.txt at 3am.

The security admin team would be interested in verifying that poor old
Joe was actually logged into his usual workstation at this point. If log
data on the workstation indicated that Joe logged out of his normal
workstation at 17:00 the previous day, and door security records could
correlate that data, then the investigation should proceed in different
directions.

There are also situations where a supervisor may need to verify a users
'timesheet' data due to fraud investigation activity - and login/logout
records may be a useful tool for this (even if it may not be the most
appropriate use of a security audit trail ;)

Regards,

Leigh.

-- 
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/