Re: access control projects

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: access control projects
Date: 28 Jun 1999 11:50:00 +0200

Next Article (by Subject): Re: access control projects don@research-cistw.saic.com (Don)
Previous Article (by Subject): access control projects don@sabotage.org
Top of Thread: access control projects don@sabotage.org
Next in Thread: Re: access control projects don@research-cistw.saic.com (Don)
Articles sorted by: [Date] [Author] [Subject]

********* ***************** ********** ****  *****   ***** ************
  To subject access control projects
  don@sabotage.org  wrote:
********** ******************** ******  ********  ******* *************

> Recently there has been increased interest in using different access control
> mechanisms. Capabilities have gotten quite a bit of press lately, and I know
> that there was once an ACL project. I'm starting a project to implement
> Domain and Type enforcement. It occurs to me that with so many projects
> working in essentially the same area of the kernel it would be a good idea
> to have a site to collaborate, and also explain the differences in access
> control systems to interested parties. I know that the RSBAC project in my
> opinion is the furthest along, so I would like to solicit your cooperation.

As far as I know the ACL projects is still working, with something like  
journalling ext3 with ACL support at the far end in 2.3 or maybe 2.5.  
There is not much to be found in linux-kernel list, though.

RSBAC is meant to be getting its own ACL module, too. This part has been  
high level designed, but not yet implemented. The delay has been caused by  
the module support recently added as well as by personal reasons (holidays  
etc.).

> Additionally, since you're already familiar with the operation of some
> important pieces of the linux kernel (the workings of the open() call, for
> example) I would appreciate if you'd be willing to share your knowledge to
> help with the project I'm working on, Domain and Type Enforcement. It works
> by grouping subjects into domains, objects into types, and assigning access
> rights from domains to types and also domains to domains. The access
> permissions are not visible to the programs, but are enforced subtancially
> as a mandatory control with a few qualifications.

This was the background I developed my Role Compatibility model on - just  
use RC Roles instead of Domains and RC Types instead of your types.

You will probably be facing similar problems to those I had in RC, like
- what is a subject
- when does a subject become an object (tracing or signalling processes)
- how do you handle domain or type changes
- how can you manage access rights efficiently
- what are the creation defaults

I recommend a closer look at my RC model.

> The server I'll be using is already set up and I'll be ready to announce it
> soon as a configurable access control effort. I just wanted to get other
> people's take on this, especially from a project as far along as RSBAC. I
> think by working together though we'll have a better change of getting
> common interfaces or changes accepted, such as getting changes made in the
> inode structure. I'm already on the RSBAC mailing list so there's no need to
> cc me.

Originally I planned to step in early in the 2.3 cycle, but this seems to  
be quite overloaded at the moment. Still I would appreciate inclusion of  
the enforcement part and the basic decision dispatcher, which already  
gives a good logging system.

I doubt whether Linus would agree to include this stuff, but maybe we  
should post a suggestion to the kernel list soon.

Amon.

--
Please remove second ao for E-Mail reply - no spam please!
## CrossPoint v3.11 ##
-
To unsubscribe from the rsbac list, send a mail to
majordomo@morpork.shnet.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.