[rc5] V3 Questions and Concerns

Eric Gindrup gindrup at okway.okstate.edu
Mon Oct 27 16:11:07 EST 1997


        Although true that Java cores are not as high-performance as native 
     cores, the extra security is likely to draw in people who would not be 
     comfortable downloading "strange" software to run unsupervised.  This 
     would increase the effectiveness of the Effort.
        The only remaining technical difficulty for me is: can an unsecured 
     Java GUI/network interface dynamically create a Java sandbox into 
     which to download and run an (untrusted) Java core?  I know how to put 
     them both in the same untrusted sandbox and how to put them both in an 
     unsecured environment, but not how to mix the two.  Being able to mix 
     would allow the trusted Java client to run trusted native cores.
        There are a whole bunch of reasons that this is a good thing and 
     the only reason I've really heard opposing it is that the Java 
     performance isn't good enough.  I counter, though, that 0kps is 
     infinitely worse than 1kps.
     
        And, a comment: *Most* OSs running the Bovine client have no way to 
     do what you mention.  Wintel and MacOS boxes don't do this.
            -- Eric Gindrup ! gindrup at Okway.okstate.edu


______________________________ Reply Separator _________________________________
Subject: Re: [rc5] V3 Questions and Concerns  
Author:  <rc5 at llamas.net > at SMTP
Date:    1997/10/24 12:11


     [snip]
     
   This is certainly a serious problem.  Much of the allure of Java is
that it allows this kind of thing (download and run random code) 
securely.  As has been shown, Java is not fast enough to be usable in 
the distributed.net effort yet, so we have to do something else.
     
     
   It's been said before but i'll say it again:  There is no substitute
for having source code.
     
     
   In most contemporary operating systems, there exist facilities for
running programs natively in a sandbox.  For example, in Unix i can 
create a special user ('distributed'), and run distributed.net clients 
as that user in a nice'd, chroot'ed, setrusage'ed environment.  The 
client program can still run amok and freak out, but it's not going to 
hurt my system, and i can just step in and kill it.
     
     
   Perhaps it would be useful to develop and distribute a wrapper for
these clients that allows the administrator to configure the amount of 
resources they are willing to part with.
     
     [snip]
     
Sebastian
     
----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the
body.
     


----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list