Security (was: Re: [DotGNU]Newbie)

[Peter Minten]

Norbert Bollow wrote:
> 
> Roger R. Smith <address@hidden> wrote:
> 
> > I am interested in security and the System.Security library, but I would
> > be more than happy to help out wherever I can.
> 
> I'll be really glad to have someone one board who is seriously
> interested in security stuff, and who can make sure that DotGNU's
> implementation of System.Security will be worthy of that name :-)

Little question, will we follow the specs or implement the DSS (DotGNU Security
System)? This is an area where it will be hard to comply with ECMA while
maintaining an own identity. My humble suggestion would be to implement DSS and
then try to emulate ECMA behaviour on DSS.

> BTW this is one of the areas where there will almost necessarily
> be differences between what Mono wants to have in that namespace
> and what we will wanr: I believe that Mono is interested in just a
> faithful implementation of whatever there is in .NET, while here
> in DotGNU we should carefully consider what extensions we want in
> order to make it meet the GNU needs... for example I think that
> we'll want our System.Security to contain extensions that support
> the standard security features of Unix and GNU systems.  For
> example, code should be able to assert that it's not running as
> root, and/or that it runs in a changeroot jail (I'd define "runs
> in a changeroot jail as "there are no entried for hard disks in
> /dev/" when there's no way to query the kernel about this).

Yes, but we need more than that. We need a unix kind of security even on the
most insecure systems that don't support multiple users in a decent way (win9x).
I'm thinking of a role system here. To start webservices you must be logged into
the DGEE (for example by --user --password arguments). If you're logged in as
root you get warnings that running webservices might be insecure.

The DSS provides an even more effective security measure though. All I/O goes
through the DSS and is checked against predefined rules (as explained in the
'DotGNU Security System' thread). This creates a really safe system. Of course
low level languages like C will be a problem since it could do nasty memory
tricks which the DSS is powerless against. However given that the primary DotGNU
languages are C#, Ruby, Python, Perl and Java that won't be a big problem.

The nicest thing about DSS is that it doesn't require the System.Security
namespace, it merely requires the interpreter to be adapted (baselib could be
overridden by another baselib). That would of course mean that you can't use the
Mono runtime in DotGNU, but I don't think that would cause major problems.

I believe DSS meets the GNU needs. It's simple (ever looked at the
System.Security specs :-), unavoidable (you can't escape the interpreter) and
even usable outside the DotGNU project. Actually if we do our job right DSS
could become a security standard for all interpreted languages and OS'es (which
would be a Really Good Thing btw).

On the technical side I expect few problems. It seems most logical to put the
DSS stuff in a lib with simple functions and link (dynamicly or staticly) to
that from the interpreter. An open call could look like this:

if (!dss_check_open(DSS_ACTION_OPEN, mode))
  throw_error(e_FileError, "Can't open file due to security restrictions");

We could also provide convenience functions like:

FILE * dss_fopen(char * name, char * mode)
{
  if (!dss_check_open(DSS_ACTION_OPEN, mode))
    return NULL;

  return fopen(char * name, char * mode);
}

The advantage of this approach is that you only need to put dss_ in front of a
few calls and that the system behaves just like it would with normal methods,
except for a few simple things. We need to adapt quite a number of functions to
make it completely transparent though.

Greetings,

Peter