Jan Harkes wrote:
>
> 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.
--- I dunno. Doesn't sound like you are talking about a non-hostile or well-managed user community. College students, maybe, but cooperating researchers trying to get a job done?> > > 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. --- I think the key words here are "determined" and "hostile".
> > > 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. --- Actually it is a 'login' UID. Authentication is done at the time of user access to the system. After Authentication they are 'authorized users'. Authorized users use subects (processes) as proxies to perform actions on or access 'objects' (files, other processes, etc). If I 'su', I need still need "the unique identifier assigned to each individual user" to do tracking with.
> Well, your authorization is not my authorization. --- I never claimed it was -- I am not speaking for you. Your defensiveness is unwarranted.
> Someone can be logged > in but not authorized as far as kerberos and Coda are concerned. --- Absolutely. Those are separate issues from this requirement. It is likely (though not certain) that the only file system we would ship for certification would be 'extX' (X=2 or 3) or xfs if that was available in the right timeframe. We would likely want to partner with an existing large distro maker such as Turbo, SuSE, Mandrake or RH (that is an example list not necessarily accurate or definitive). All of those distro groups currently use 'ext2'. So our official evaluation would likely be using that file system. It is unlikely kerberos would be used in the base system as well. Each file in the "Trusted Computing Base" has to be analyzed for behavior and have a complete description of it's Security Relevant Features and its Security Enforcing Features. Writing an analysis to meet CAPP specifications would be be alot of work for Kerberos. It's also not a piece of software needed to meet the CAPP profile.
> 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.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; ---- Here is your definition for the link between subjects and users. Each subject is to be tracked back to a unique identifier assigned to each user.
> 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. --- Yes you can do that. I feel it would be more difficult to do the session ID than the login ID. If you want to clearly define the semantics of a session ID (when it can be set, is it secure (CAP needed), at what points are the generated) and formulate it into a policy statement and write the kernel patch for it -- go for it. I'm not stopping you.
I'm proposing 1 type of security feature that supports a particular component of functionality. It doesn't mean it's the only one possible. It doesn't mean it will exclude others. It is simply the most direct route and one that has historical precedent (HP-UX, SCO, IRIX et al.)
> 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. --- The requirements specify that a subject ID would have correspond to a unique identifier that is assigned to each user. A static assignment of unique ID's using the LUID concept is the most straightforward. A dynamic assignment at each login would satisfy the requirements but would also require more post processing and a, as yet to be defined, semantic and implementation.
-linda
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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