[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: S11001001
Subject: [DotGNU]putting the "Secure" in "SEE" (was Re: SEE)
Date: Tue, 11 Jun 2002 23:00:19 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020608

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:

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

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

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"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]