Re: [Vrs-development] Re: [DotGNU]VRS architecture docs

[Bill Lance]

--- Norbert Bollow <address@hidden> wrote:
> Bill Lance <address@hidden> wrote:
> 
> > I think we are talking about two different things
> > here.
> 
> Yes, about a practical problem (that makes the
> system
> difficult to debug) and about a security problem. 

Ok  .. those two things to  ... :)

Your right,  a good debugging framework needs to be
engineered into the code, preferable one that can be
striped from the final runtime.


> 
> > The real problem is a hostile host root user.
> 
> Yes.  This is the very serious problem.  I don't see
> any way in
> which a host could be worthy of more trust than you
> have for
> whoever has root on that host.
>

Hummm ...  this might point towards a coping
mechanism, if not a solution.  A trust matrix built
into the cluster management filters.  Let me expand a
bit.  There is table of information kept on each LDS
node that is used job distribution and task delegation
in the Custer Manager.  This includes things like
assigned cpu resources, disk space, bandwidth, etc. 
An additional parameter could be a level of trust
index  Assignment of the index is a cluster
administration matter.  The trust level would enable
or disable certain functions in the local LDS.

Level I - Completely trusted
        Full funtionality

Level II
        Cluster management functions - off
        Service request fulfillment  - on
        Repository storage           - on

Level III - Untrusted
        Cluster management functions - off
        Service request fulfillment  - off
        Repository storage           - on


In this way, an untrusted node could contribute disk
space, but it would have no information about that
data nor about the rest of the VRS cluster, nor could
it effect the rest of the cluster in anyway.

This level of functionality is controled by the
Cluster itself, so it can not be overridden by the
LDS.  When a node logs in, it's level determines what
data is shared with the new LDS and wether any of the
running nodes will listen to any cluster or repository
management messages from the untrusted node.

If the cluster will not give it the necessary data to
begin with and will not listen to management messages
from it  ... well there's not a damned thing it can
do.

Why would someone run such a limited LDS node? 
Because they would still have access to their personal
data placed into the cluster.  They could replace or
withdraw the dataset and files they owned.  And their
files and dataset are still exposed to the net as any
other one is.  They get the same services as any other
subscriber to the Cluster.  
 
Now the matter becomes a trade off for the cluster
administrator.  This is a human somewhere that set the
cluster up to begin with.  They can protect the
running Cluster from an untrusted node at the cost of
SOME of the resources it could have added to the total
cluster pool.  But it can still contribute mirror
memory space for the Repository.






__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com