[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH] support using pam_audit.so in "account" stack

On Mon, Feb 21, 2005 at 06:13:37PM -0800, Casey Schaufler wrote:
> Nope. On the other hand, I cannot point to a system that has been
> successfully evaluated that does not do this.

RHEL3, SLES8 and SLES9 have all been successfully evaluated as CAPP
compliant with no logout messages...

> This will, of course, depend on how carefully you've defined a
> "session". A detached process that is not associated with a controlling
> tty cannot interact with the user, hence need not be considered a part
> of the user's session.

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.

> On the other hand, the collection on processes started by a cron job is
> a session, even though no user is interacting.

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

> My point? It's not enough to have code that does auditing. No
> evaluation team, even a Spanish team using the Common Criteria, will
> have any patience with you if you take the attitude of "show me where
> it says I have to do this". Especially if you use the fact that the
> system makes audit hard to explain as the grounds for your argument.

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

> - I found the event I was after. How do I find out when the evil person
> logged in, and when she logged out?

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.

> A logout message does wonders toward having a compelling story without
> this level of audit.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]