Re: [Openmosix-devel] openMosix-devel Digest, Vol 3, Issue 10

[Ian L. <ian...@mi...>]

Yeeeaah, Ian Latter didn't have this particular security issue
because he classified the entire cluster as a single resource
- not each node.

The problem you've got, if I read your intent correctly, is that 
you want a user to dedicate a node resource to a project .. 
however, openMosix doesn't support that kind of trust .. i.e.
the project ultimately hands over the keys to the entire cluster 
to the user who just supplied the resource (as well as every
other user who supplied one or more resources).

See, Seti@home (and others) get around this by;

  - Not working in a peer model 
       (i.e. node resources are "clients", the "central server" is
        ultimately god, clients don't get to query god, clients
        don't get to interact with clients)

  - Not trusting any one single client result
       (i.e. all client results are tested at least twice by having
        the same work unit performed by multiple clients and
        comparing the outcomes centrally)

  - Data migrates, not executable code
       (i.e. when a client says goodbye, it doesn't hand back
       16Mbytes of executable code to be completed at god -
       it hands back 256k of result data to be assessed by
       god)



Off the top of my head, you have a number of issues that you will
need to address, a couple will be easy, but not others;

  - clients must not migrate programs to clients
      (You can try and control this via packet filtering and 
       oM map control)

  - clients must not migrate new programs elsewhere
      (You can try to prevent jobs from migrating to the "central
       node" by using oM's native controls (/proc entries))

  - "central node" must not receive and run exectuable software
     that has come from "out there"
      (You would need to modify oM itself to prevent this; make
       it a type of client/server model - maybe add a trust flag
       on the parent stub ... dunno)

  - To my knowledge, sending garbage to the oM network 
     sockets still produces faults;
         http://xforce.iss.net/xforce/xfdb/8927
       (You "central node" will require oM ports to be exposed to
         "untrusted" clients - you will need to find a work-around or
         fix for this issue)


The openMosix security model only works when you treat the
entire cluster as a single computer of a single user (class). All
of my security work with openMosix was spent making sure
that the cluster owner was the only player in the cluster, and 
that everyone else was stuck "outside".

I think you've received some good advice for picking a different
base model for your solution ...




----- Original Message -----
>From: <ma...@ds...>
>To: <ope...@li...>
>Subject:  Re: [Openmosix-devel] openMosix-devel Digest, Vol 3, Issue 10
>Date: Sun, 13 Aug 2006 06:19:25 -0700
>
> Of course, but if Ian Latter can solve those problems, I'll figure it out
> too.
> I'm trying to figure out if I should go with 2.3 or 2.6.
> 
> > On 8/10/06, ma...@ds... <ma...@ds...> wrote:
> >> Sounds to me like 2.4. is less overhead for the nodes.
> >> The head node is the one that would benefit from 2.6.  Am I reading that
> >> correctly?
> >
> >
> > Agreed. You don't want to do this with oM.  Security implications
> > abound.
> >
> > Matt
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> openMosix-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
> 


--
Ian Latter
Late night coder ..
http://midnightcode.org/