On Mon, 2005-02-21 at 13:58 -0600, Klaus Weidner wrote: Yes, Steve was likely assuming that it wouldn't work because we couldn't use pam_selinux with sshd. But that is due to the fact that we also need to relabel the pty in pam_selinux, which is not an issue for pam_audit. Hmm...for pam_selinux, we have to bracket the pam stack with pam_selinux close and pam_selinux open to ensure that the SELinux exec security context is not set until _after_ all other pam modules (and their helpers) have executed on session open and is closed _before_ all other pam modules (and their helpers) execute on session close. Is that a concern for the loginuid? -- Stephen Smalley <sds(a)tycho.nsa.gov&gt; National Security Agency

On Mon, Feb 21, 2005 at 03:18:55PM -0500, Valdis.Kletnieks(a)vt.edu wrote: Try the following: *** login session required pam_selinux.so close session required pam_stack.so service=system-auth session optional pam_console.so session required pam_audit.so session required pam_selinux.so multiple open *** sshd session required pam_stack.so service=system-auth session required pam_audit.so You don't want a new login UID assigned if someone uses 'su', 'sudo' or equivalent (that's the entire point of having a login UID maintained separately), so putting it into system-auth is not a good idea. -Klaus

On Mon, Feb 21, 2005 at 05:21:40PM -0500, Steve Grubb 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. -Klaus

On Mon, Feb 21, 2005 at 02:44:10PM -0800, Casey Schaufler wrote: Can you point to a specific requirement in CAPP related to that? Note that even if you have logout records, they are not a reliable indication that the session is complete, there may be background processes launched by the user that keep running (and potentially generating audit events) after the logout message. If you need that kind of information and you aren't satisfied with the login UID, you need to trace all fork/exec/exit events for the session. -Klaus

On Mon, Feb 21, 2005 at 06:13:37PM -0800, Casey Schaufler wrote: RHEL3, SLES8 and SLES9 have all been successfully evaluated as CAPP compliant with no logout messages... Well, they are running on behalf of that user and need to be audited in the same way as if the user were still logged in. And the "interactive" distinction is fuzzy at best - what about programs run in a "screen" session that get detached and reattached later? Or a background program that opens a network socket accepting interactive commands? That's why a logout message is far less informative than a login message, it doesn't correspond to any particularily interesting or security relevant event. Agreed, that's why crond needs to be instrumented to set up a proper audit context for the code run on the user's behalf, including the correct login UID. It doesn't mean that cron needs to write login/logout records. Well, I'd have little patience with evaluation teams that expect me to implement something that clearly isn't required. It's the evaluator's job to verify that you correctly implement the features your product claims to have and that the claims match the chosen profile, not to dictate a design. The login message will be present, and tells you interesting things such as when and from where the person logged in and what authentication method was used. Instead of asking for a logout time, the more interesting question would be if any processes launched by that person are still active, and a logout message doesn't help determine that. A logout message would be useful if the system guaranteed that all processes launched by that user are definitely terminated at that time, but that goes beyond the requirements of CAPP. Hmmm, the type of evaluation I'm used to generally involves testing instead of having the developer tell stories ;-) Maybe we'll just have to agree to disagree here, there are different ways to approach this issue. The CAPP audit requirements are fairly basic and aren't intended to be useful for all purposes. -Klaus

On Mon, 2005-02-21 at 18:13 -0800, Casey Schaufler wrote: 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/

On Tue, 2005-02-22 at 11:00 -0600, Klaus Weidner wrote: True enough. I stuck login/logout auditing in the 'too hard' basket in Snare for a fair while, for this (and other) reasons myself. However, If I printed out the number of requests I'd received for login/logout data in Snare, I'd be swimming in a paper storm at the moment. ;) My suggestion is 'build it, and they will come'. Up until recently, SSH on solaris didn't generate a login/logout message either, but the code has been modified due to many customer requests. Cover the core feature set that most people are interested in (interactive login/logout), and other applications such as vsftp/ssh etc, can be integrated on a priority basis later on down the track. L. -- Leigh Purdie, Director - InterSect Alliance Pty Ltd http://www.intersectalliance.com/