Re: access control projects

From: don@research-cistw.saic.com (Don)
Subject: Re: access control projects
Date: Wed, 30 Jun 1999 22:58:36 -0700 (PDT)

Next Article (by Subject): Bug in 1.0.9a-pre2 and possibly others ao@morpork.shnet.org (A. Ott)
Previous Article (by Subject): Re: access control projects ao@morpork.shnet.org (A. Ott)
Top of Thread: access control projects don@sabotage.org
Articles sorted by: [Date] [Author] [Subject]

> 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.).

I see. Personally I think ACL's would be a useful addition, and probably
make NTFS implementations a lot easier, but I'm inclined to believe that ACLs
will be very difficult to implement in a way that will make for a smooth
adoption phase. I mean, HPUX for example has had ACL's, and they're basically
unused. However I will make a note that RSBAC is attempting ACL's.

> > 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.

> I recommend a closer look at my RC model.

Although you RC appears to have the same general construct
(Subject->Role->Type->Object) and have similar transition mechanisms, I
think there are substantial differences. I am trying to do what is basically
a reimplementation of TIS's Domain and Type Enforcement, although enhanced
in several areas. (e.g. the configuration language is a little easier to parse,
and I think I've figured out how to tighten down some problems they had to
ignore.) In any case it will be a fairly similar design to TIS's, and I
believe it is more powerful and flexible in a couple of ways. One of which
is that it would have no relation with the UID, so an ftp daemon running as
root (wu-ftpd so we'll know there are plenty of stack exploits) can be kept
away from syslogd running as root, both of which are kept away from the super
user who has uid 0 also. Ultimately I hope to make a uid 0 shell available
from an inetd port and not have to worry about system security. 

Since RSBAC is lightyears ahead of all the other projects, I'm hoping at least
for a peaceful coexistance. ;)


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

I'm hoping that that would be one of the effects of an inter-project
cooperation. I've set up a site which explains the different access control
systems, and links to the various projects. (It will be the same site that
I host my own project from)  I would like, if there is enough interest, to
have a mailing list shared by the different projects; so that when Linus gets
hit by our list of demands that not only will it meet everyone's needs, but
also carry more weight because it's the request of say 5 different projects.

Also, I think that having multiple projects advertised all from the same place
will get more people interested in alternatives in access control; they'll
start thinking, hey these access control ideas are really going to take off.
I will announce the site next week, but considering RSBAC has so much code
written I don't you to feel like I'm trying to leverage a site on top of you.
I really think I can get at least one other group to cooperate with our
respective projects and try and coexist, if there isn't any objection here.

The server is being hosted by my employer (a large security group) and I'm
meeting with a lawyer tomorrow to make sure he's ok with the disclaimers how
it's not the opinion or a project of the company, etc.

So it should be up soon.

Thanks

Don
-
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.