Re: [DotGNU]Authorization and Security

[Mario D . Santana]

It sounds like someone needs to step up and organize everybody's 
thoughts on DotGNU+auth.  Didn't I hear Mike say he was going to be the 
DotGNU auth guy when he came back to life in a couple of weeks?  Since 
you (Chris) and I are each approaching the question from our own 
viewpoints, a third person to sort of represent the bigger picture 
(which contains us both) would bring some necessary sanity checks with 
them.

On Friday, July 25, 2003, at 12:59 PM, Chris Smith wrote:

> Yep - webservices can be protected from each other by the DGEE itself
> [...]
> it sandboxes the whole dgee and not on a 'websevice [set]' level.

Yeah, fine-grained WS sand-boxing sounds necessary, but don't take my 
word for it.  I haven't thought about WS the way you have.  In any 
case, MACS provides for dual-keyed fine-grained access control right 
now, which it uses to protect user profiles.  Given your 'webservice 
[set]' terminology above, this sounds like it would do the trick here.  
If not, there are plans to expand MACS' fine-grained access control to 
be N-keyed.

> More thought needs to go into this.

Clearly.  ;-)

> > > 2. Protect the webservices we are running and their data from 
> > > programs
> > > running outside the execution environment.
>
> If we consider the Unix environment, this is probably pretty much 
> protected as
> is - unless you're root ?
> Again the same problem with data.
> [...]

If you want to depend exclusively on the filesystem for environmental 
security, I think you'll be disappointed.   Probably the fine-grained 
sand-boxing above would help this.  (chroot?)  But IMO the right way to 
do this would be to use the sand-boxing stuffs in the VMs.  A DGEE 
administrator could make the call to allow a VM that has poor 
environmental sand-boxing at her discretion.  Note that pnet is missing 
these pieces, but Rhys has mentioned that they're in the works.

> Again the DGEE protects webservices from interfering from each other by
> running them in seperate processes.  Does that have a bareing here?

I think that's as much as can be asked for.

> Data... if you're talking about storage then again this has a whole 
> sea of
> discussion coming.

Again, it seems to me that this could be handled by the VM.

> The DGEE has good logging.
> For security auditing though and auditLog is required.  This can be 
> handled
> internally by the DGEE if required and any applications/Webservices 
> running
> in the DGEE can - if required/allowed - perform audit logs.  I don't 
> know how
> public this would be - I presume only architectural componets of the 
> security
> system/dgee would have access to this interface.

Yes, a separate, discreet audit log is a must-have.  The DGEE can do 
all the logging it wants, but the security subsystem should keep an 
audit trail independently.  If the DGEE hands off security operations 
to a third party like MACS, then it doesn't have to log more than a 
note to that effect.

The "interface" doesn't exist -- MACS can be configured to produce an 
audit trail, or not.  If yes, then *all* operations are logged there.  
The format, verbosity, etc. of the trail may become configurable at 
some point, but I don't see a benefit to being able to do this 
programmatically.  In fact, the auditing mechanism is independent of 
all the other MACS functionality, tying directly into the framework to 
intercept all actions.  Making it available for configuration (other 
than the MACS config file) would actually lessen its guarantees, I 
think.

> [...] There are two distinct areas of athentication within the dgee.
> 1) Authentication _with_ the dgee so that the dgee can authorise 
> access to ITS
> services (administration etc)

To do this using MACS, the DGEE itself would call the MACS API.

> 2) Authentication with webservices (or groups of) running _within_ the 
> dgee.
> This is application level, but could be facilitated via some dgee level
> components on behalf of applications so they don't have to do all the 
> work
> themselves.

Of course.  Each webservice can choose to use MACS' API or any other, 
or even roll their own, regardless of how the DGEE handles its own 
security.  However, if they both use MACS, they can play together in 
probably very interesting ways, since they might use each other's user 
data for their operations.  Eg, the DGEE admin UI might be an 
independent webservice, using MACS to discover and modify the security 
settings used by the DGEE proper to set up sandboxes, etc.

> Just random bits :o)

Well, pseudo-random.  Good talk, though.  =)

Cheers!

mds