Re: safe cpu'ing

> One fear may be what you are giving the other system access to by cpu'ing there.
> If you are cpu'ing to a taken over system, it can get at anything on your system
> via your /mnt/term.  I just had a talk with ehg about this.  What I'm intending
> to do is create a program that mounts on '/' (much like iostats) and creates a
> a gui in a window (much like auth/fgui).  It can take a list of acceptable files
> (or file trees or regexps).  Whenever anything under it asks for access to a file
> outside the list, you get a 'mother may I' request in the window.  You can click
> 'no' 'yes for this file' 'yes for this subtree' 'yes for this directory' or
> even substitute a file name to use intead.  It just tacks what you say onto the
> list.

a friend of mine got hit with the first (i believe) ELF32 virus that
crawls the fs and infects every executable it can.  this was about a
week ago, but prompted discussions on this very same topic.

the solution i was toying with was to mount /mnt/term read only.  this
is slightly more draconian than most people would like it to be and
doesn't really solve problems like displaying graphics remotely.  in
fact it's a bad solution.

> 
> This will take some work to not be a pain in the ass.  However, this is a real
> problem that the Condor people have.  I think this interactive solution can
> be good enough for us.  Condor is trying to solve it by analyzing the programs
> being sent places and making sure that the system calls being sent back are
> 'reasonable'.  That's not really possible in our world (or probably in theirs,
> for that matter).
> 
> Comments?

how about mounting/binding the stuff that's supposed to be read only
as read-only, only?  how much of /sys or $objtype/ needs to be writeable?
updating the system could be done locally, in the privacy of one's
namespace.  unless people want to update remote sites over the 9grid...