> Well i suppose if an application only gets the common rights of itself
> and the user that's executing the application it would help a lot to
> reduce security problems.
> It might require us to automatically enforce certain (default?) rights
> onto applications.. because most programmers, unfortunatly, do not
> take the time to limit an applications rights...
[Jonathan Dickinson] 
How about forcing developers to ask for rights. I.e. Everything is disabled
by default (which is a good security practice in itself).

> If an application uses plugins, and has full rights.. and then gets to
> impersonate someone.. a plugin would get full rights to that person's
> account..
> That's a bit scary.. we can't assume that all users are expert users..
> that faulty assumption is one of the roots of most security problems
> in modern day operating systems..
[Jonathan Dickinson] 
Very true. But with the Singularity OS one does not load types into an
assembly (they cannot load more code once they are loaded), thus the
developer would need to create a SIP for that plugin and could limit it from
there. E.g.

Public void LoadPlugin()
{
        Plugin.Load();
        // Plugin has NO user rights at this point.
        RightsAttribute.Apply(Plugin, RightsAttribute.CurrentUser.Rights);
        // Now the process has rights.
}

> So the default should be 'completely locked down', and an expert user
> could override it if for some reason he'd want to...
> (but applications shouldn't be able to simply do that.. basically only
> a handfull applications that came with the OS that have the right to
> do so)
[Jonathan Dickinson] 
As per my Primary/Secondary/Tertiary post. The ability to raise rights falls
away at the secondary level. To install assemblies at the secondary level
you need certain rights yourself.

Remember, at the point at which we check if Joe can write to
/Assemblies/Kernel we need to be able to assign rights. To clarify, a bug at
this point would mean that a user could access the entire system: e.g.

// In a secondary assembly.
Public void SaveAssembly(string location, byte[] data)
{
        If(!RightsAttribute.HasRight(RightsAttribute.CurrentUser,
Right.WriteSecondaryAssembly))
                Throw new Exception();
        // Write the assembly.
}

It's hard to explain :(.

> 
> As for .net applications requiring it, there's nothing stopping us
> from more or less sandboxing .net applications (putting a layer in
> between) and doing our own thing for the rest of the OS... (not that
> that's an easy thing to do)
> 
> It would definitely help if we only use impersonation at the "logging
> in" level, physically behind the machine and remote.
> Basically only a handfull of applications would have the right to
> 'impersonate'..
> (and even fewer would have the right to modify that right ;)
[Jonathan Dickinson] 
Hmm... would work well. For example, the FTP server would need a secondary
assembly installed (which makes perfect sense because you would need admin
rights to install a FTP server. No admin rights, no install server, sorry
:).


> 
> I'm just "thinking out loud" here.
> 
[Jonathan Dickinson] 
Me too :). What we could also do is to actually require a logged in user.
"How do we do impersonation?" I hear you cry. As follows:

Public void LogUserIn()
{
        UserSpace user = new UserSpace(this.username, this.digest);

        User.LogIn(); // If the user is already logged in this would get a
handle to that login.
        Process p = User.RunProcess("FtpWP.exe");

        // We add a reference to the FtpWP assembly, even though we don't
call anything from
        // within our own code.
        FtpWP.Worker worker = user.RootProcess.GetProxy(p.Id,
typeof(FtpWP.Worker));

        This.Worker = worker;

        Worker.Start();
}

Public byte[] GetFile(string filename)
{
        Return Worker.GetFile(filename);
}

So I am sure you get the idea. We /actually/ log the user in and set up a
IPC to that user's process. No impersonation and it is all very clean...

Jonathan Dickinson


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers

Reply via email to