[DotGNU]putting the "Secure" in "SEE" (was Re: SEE)

[S11001001]

Hey Rhys, I'd like your feedback on what you can do about security in 
the plugin.

James Michael DuPont wrote:
> Can SEE be used to check the certificates of the
> clients from a CA?

I think after the basic code is finished, I will add support for OpenSSL 
as the next priority, as I believe that almost all internet traffic 
should be encrypted, including that which need not be, so as to keep 
from prying Evil Government eyes. However, the biggest ? here is the 
auth model; I really have no idea exactly how that will work with SEE. 
All I know is that my SEE should be modular enough to add it in later.

BTW, what I meant by "encryption technology" in see-content was 
something like file signing. I was really vague about there, because the 
description is meant for users; but I'm really vague about anyway, again 
because of the auth thing.

> What if the client is not secure
> and allows usage from non secure software? How can you
> check the chain of calles back the the user if they
> are secure?

Not sure what you mean here; the SEE model contains 6 different servers 
and 6 different clients:

servers:
the listener for seerunning (user invocation of a service)
the network listener (port connections for service stub)
the root listener (manages other SEE instances on machine)
the non-root listener (receive requests for webservices)
the actual webservice server (PE)
the plugin API listener

clients:
the SEE->SEE service stub getter
the root connector (register services with root)
root's message passer (tells others about service requests)
seerun (user)
the plugin
the service stub (PE, connects to original webservice)

It's an IPC nightmare, and it's all mine for now....

Which calls do you mean? If you mean calls in the application, SEE 
doesn't touch those. It is up to the plugin to effectively use the 
pluginAPI to get security info.

As for security, one reason I disagree with myrddian's model is that he 
seems to think that jailing is a one-size-fits-all solution. Security 
only comes through vigilance, not to mention good stub design. I can't 
fix all security flaws in the webservices from the SEE standpoint.

As for ident/auth, YES. This is the security strength of the SEE, and 
why the name is still valid.

Hmm, some of this kind of thing should go in the pluginAPI, i.e., the 
original host is offered, and plugins can limit network connections to 
back to the original host. It's akin to cookie security, but harsher. 
Then I think, well, you can change this setting in one of the various 
see.conf files.....all further musings welcome!

--
Stephen Compall
DotGNU `Contributor' -- http://www.dotgnu.org

My views about copyright take an hour to expound, but one general
principle applies: it cannot justify denying the public important
freedoms. As Abraham Lincoln put it, "Whenever there is a conflict
between human rights and property rights, human rights must prevail."
Property rights are meant to advance human well-being, not as an
excuse to disregard it.
        -- RMS, "The GNU GPL and the American Way"