On Mon, Apr 17, 2000 at 12:49:39PM -0700, Linda Walsh wrote:
> 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.
Ok, let's go back to the code snippet that was posted earlier in the
thread by Albert Calahan.
> int sysluid(int arg){
> int old = current->luid;
> if(old) return old;
> current->luid = arg;
> return arg;
> }
And munge it a bit,
static int global_audit_counter = 1;
int sys_auditid(void)
{
int id;
lock_kernel();
id = current->auditid;
if (id) return id;
id = global_audit_counter++;
current->auditid = id;
unlock_kernel();
return id;
}
How is this less secure than the luid?
How is this usable as an equivalent to the luid?
Auditable events include setuid changes, so the _first_ setuid which
is called for this auditid is equivalent to the proposed luid. And
it will be logged by the auditing mechanism.
> 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.
Hmm, doesn't look to difficult to me. It is not exactly the PAG I
mentioned before, but this looks a lot more useful to me. How do you
like the semantics and implementation?
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