Re: [DotGNU]Authorization and Security

[Mike Peters]

On Fri, 25 Jul 2003 16:23:43 -0400
Mario D.Santana <address@hidden> wrote:

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

I'm off on holiday tomorrow for 2 weeks and so will have very limited
internet access but I'll try and draw a broad picture of the way I see
things working conceptually before I go.

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

The way I see authorization of a process going runs something like this:

1. At the highest level, user X tries to connect to ws Foo from address
a.b.c.d, if this is not allowed we throw a SecurityException
immediately.

2. If the call is theoretically allowed we drop to the level of Code
Access Security which is the job of our sandbox/execution environment/VM
whatever you want to call it. At this level we need to police a number
of things such as type safety and integrity of the code/packet/message,
namely, is the System.Security info contained therein type safe and
untampered with?  ie is it really what it says it is? If not we throw a
SecurityException.

3. ws Foo decides what to do based on the Security info - note Foo may
have a stricter or more relaxed policy than the environment it is
running in in this respect, that is entirely down to the
developer/administrator of the ws not the server admin. The sanbox, at
this point has only made a security decision at the highest level (like
a firewall) and checked the integrity of any message.

4. Foo may now need to access system resources or call another ws
internally. If the latter we jump back to 1. We need to be able to
finely control and police any calls to system resources with our
execution environment. Any access to the underlying OS by a WS must go
through us and be checked for integrity (as in 2.) as well as whether
the correct permissions have been obtained
(System.Security.Permissions).

When it comes to accessing sytem resources our default policy must be to
deny any access to the underlying OS/filesystem by any WS which is not
100% trusted. I've outlined how untrusted services can be given access
to data on the underlying system below, the same concept can be expanded
to resources other than data.

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

Firstly we never allow a process running in our sandbox to ever have
direct access to underlying resources unless we 100% trust it. We can
allow an untrusted service to access data on the sysem using the concept
of Isolated Storage (System.IO.IsolatedStorage). Isolated storage is
analogous in a way to chroot in our non-ws world. Each application is
assigned its own unique storage area which is isolated from the storage
areas of other applications. Where this area is actually located on the
filesystem is hidden from the user/ws developer and is accessed
transparantly by calls to System.IO.IsolatedStorage, the admin of the
execution environment sets, for example, $STORAGEROOT and
$APPLICATIONSTORE/$USERSTORE and any files are written directly to here
or read from here. This has the added value of providing some level of
cross platform/installation portability as developers never use/need the
full path to data. The admin of the server can set sensible permissions
on his filesystem and not worry about malicious access from web services
(ie a user tries to write /usr/local/bin/evilscript.sh will actually
write to $STORAGEROOT/$USERSTORE/usr/local/bin/evilscript.sh and he will
never be able to execute the script because, a) he doesn't know the
value of $STORAGEROOT/$USERSTORE, so doesnt know the true location, b)
the server admin has made sure that any files written to $STORAGEROOT
are not executable and c) the execution environment strictly
controls/prevents execution of any scripts by any ws in $STORAGEROOT
anyway)

I'm going to stop there for now as I want to get this off ASAP and I
think there is enough for discussion here for now.

-- 
Mike
Web Site: http://www.ice2o.com
JabberID: address@hidden
Registered Linux User #247123

It was all very well going about pure logic and how the universe was
ruled by logic and the harmony of numbers, but the plain fact was that
the disc was manifestly traversing space on the back of a giant turtle
and the gods had a habit of going round to atheists' houses and smashing
their windows.
(Colour of Magic)