On Mon, Apr 17, 2000 at 08:26:33AM -0700, Linda Walsh wrote:
> These are some basics from CAPP that may explain
...
> events which occur within the system. The CAPP provides for a level of
> protection which is appropriate for an assumed non-hostile and well-managed
> user community requiring protection against threats of inadvertent or
> casual attempts to breach the system security.
...
LUIDs are not very useful for these stated goals because;
1- They don't keep track of people who managed to breach security by
_avoiding_ the identification and authorization steps.
2- if the perpetrator recovers a password (sniffing/social-engineering/
rubber-hose tactics), his actions are indistuiguishable from those
made by the real user.
> The profile is not
> intended to be applicable to circumstances in which protection is
> required against determined attempts by hostile and well funded
> attackers to breach system security.
You don't need to have a lot of funding for buffer overflow exploits or
social engineering type attacks.
> All individual users are assigned a unique identifier. This identifier
> supports individual accountability. The TSF authenticates the claimed
> identity of the user before allowing the user to perform any actions
> that require TSF mediation, other than actions which aid an authorized
> user in gaining access to the TOE.
> -------
I still haven't seen anything in these excepts that states the kernel
should audit based on the local user-id.
Well, your authorization is not my authorization. Someone can be logged
in but not authorized as far as kerberos and Coda are concerned. The
thing I've been talking about is splitting up identification (tracking)
and authentication (associating identity with a user). Identification is
done in the kernel, authentication is policy and therefore belongs in
userspace.
So, let's start reading the CAPP document (CAPP 1.d), and surprise,
surprise, I found the following:
5.1.1 Audit Data Generation
...
2 The TSF shall record within each audit record at least the
following information:
a) Date and time of the event, type of event, subject identity, and
the outcome (success of failure) of the event;
...
And reading further, I find that a clear difference between "user
identity" (authenticated) and "subject identity" (tracked) is used all
over the documentation.
The official document clearly states:
5.1.3 Audit Review
...
2 The TSF shall provide the audit records in a manner suitable for the
user to interpret the information.
...
5.3 Identification and Authentication
5.3.6 User-Subject Binding (FIA_USB.1)
1 The TSF shall associate the following user security attributes
with subjects acting on behalf of that user:
a) The user identity which is associated with auditable events;
b) The user identity or identities which are used to enforce the
Discretionaty Access Control Policy;
c) The group membership or memberships used to enforce the
Discretionaty Access Control Policy;
7.2 Security Requirements Rationale
7.2.2 Complete Coverage - Objectives
The following discussion provides detailed evidence of coverage for
each security objective:
...
O.AUDITING
Security-relevant actions must be defined, auditable [5.1.1], and
capable of being associated with individual users [5.1.2, 5.3.6].
...
So, we can definitely audit the subject identity and associate them with
user identity at the time of the audit review. I don't see any reason
for an LUID. I do see a reason for a subject identity, this has to have
the right granularity for reliable audits. Maybe it then becomes close
enough to the AFS PAG concept that Coda can use it for it's user-subject
identity binding as well.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:11 EST