Jan Harkes wrote:
>
> 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 [not] usable as an equivalent to the luid?
--- It provides less flexibility in the user space to implement policy. For example. I've been mulling over how to solve the daemon vs. root conundrum. It seems that first thing init might do is set_luid(daemon). Then it spawns all it's stuff. Then login can do a 2nd set on an an incoming user (including root) and *drop* CAP_SETLUID. So normal even root couldn't change it again directly. Root would have to use some sort of direct I/O / writing to memory at the right spot, etc. Obviously no problem for a knowlegable and determined attacker, but that isn't what this feature is aimed for.-l
-- 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:12 EST