--- Klaus Weidner <klaus(a)atsec.com> wrote:
It's a bit more complex than this - CAPP requires
that any actions on
behalf of a user happen only after authentication,
which is done
centrally through PAM on Linux systems.
All users must be authenticated, and all their
security relevent actions must be audited.
Putting the
audit hooks in PAM
ensures that any user actions can be audited
properly after
authentication.
Only so far as the authentication is valid.
If there has been no authentication, the actions
must not be considered
to be on behalf of a specific user.
No action can be performed on behalf of a user
that has not been authenticated.
Note that
running as a non-root UID
doesn't automatically mean that it corresponds to a
human user.
Ho boy. This can legitimately be true if it's an
administrative UID that no human ever uses. This
does not mean that an action on a server doesn't
have to be authenticated just because you don't
know that there's a human on the other end.
But it's
obviously unacceptable to run anything with the
rights of a human user
based on data received from the network if the
authentication steps were
not done. This rules out passwordless rsh and
similar abominations.
Almost. The Irix B1, CAPP, and LSPP evaluations
allowed passwordless rsh in the case of a common
administrative domain. If the client and the server
are administered together and the audit trail is
combined, you have everything you need.
The same type of problem appears for cron and at,
these services must
ensure that the commands get run with the
credentials of the user who
submitted them.
Hee Hee Hee. I did audit for cron years ago. They
tell me I've recovered, but the twitches come back
sometimes.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250