[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:
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"
- [DotGNU]putting the "Secure" in "SEE" (was Re: SEE),
S11001001 <=