[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Authorization and Security
From: |
Mario D . Santana |
Subject: |
Re: [DotGNU]Authorization and Security |
Date: |
Fri, 25 Jul 2003 16:23:43 -0400 |
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