Hi,
I'm the developer of this Appliance and first I'd like to thank you for taking the time to read up on it and comment about it
To answer a few of the questions you've raised :
For the concept to work users will need to install software on to their appliance >>and they will only do this if they intend to use the software themselves.If a user >>actually uses the VM for their own purposes, the security benefits of shielding the >>host OS will largely be lost as the user will be operating in the same environment >>that they are sharing with anonymous users.
Not quite. This appliance is not intended to replace the Host Operating System as the primary working environment for the user. It is supposed to only provide him with the luxury of providing a mechanism to carry his favourite software and operating environment with him where he goes, so for e.g. if a C++ developer suddenly feels the need to code while he isn't at his primary working environment, say if he is in a cyber cafe, then he still can. It also provides the added and more potent flexibility of providing him access to tools,environments and processor platforms he himself may not be having.
One of the prime reasons people don't want to share their environment with anonymous users is to protect their confidential Data. Since this appliance does not aim at replacing the Primary OS as the working environment of choice a user would typically still continue to have his confidential data on his orignal setup while using this appliance as a Mobile Workbench to access his favourite environment and tools while he's on the go.
Therefore even if an anonymous user manages to trash the virtual appliance all the user has to do is reload it from his CDROM or USB drive and he's back with his appliance running in no time. Something he can't afford to risk with his primary working environment.
That said. Future versions could tighten screws further by simple mechanisms such as having a guest account on your Virtual Appliance therefore an anonymous user would log in to that account and would not have the privileges you have to mess up your appliance or by running this guest account in a Chrooted environment therefore restricting access.
As it stands this appliance is "Proof Of Concept" of what could be attained once you decide to share your Software, Operating Environment and Computing Platform for all to use. As I've outlined in the slightly more detailed documentation found in the file eBrainPool.txt when you unzip this appliance, I expect a lot of refinements especially with regards Security. However most of these issues are well understood and none of these issues are insurmountable.
Are there measures in place to prevent an anonymous remote user from gaining >>root access?
First. The current Proof Of Concept publishes the Root Password so people can add software to it. This password is meant to be changed by a user once he uses this appliance for the first time.
Now to the issue of preventing any future privilege escalation by a user connected to the host. The strength in preventing this is determined largely by the Host OS used and it's configuration. For the purposes of this proof of concept implementation is done only on Linux with the Debian distribution. Most current OS's try their utmost to prevent this from happening. When you're connected to a Webserver or a FTP server there's always the risk of an individual hacking/cracking his way in. Apart from OS strength additional steps could be taken in future versions which could thwart this risk such as running the guest user account in a chrooted environment.
Just because a system has an application installed doesn't mean that the >>application is correctly configured and will work as expected.
True. But as you've pointed out yourself above that a user would probably have applications installed which are of some use to him and in order for them to be of use to him they'd need to be functional.
That said if a user discovers an application on the host isn't working he can always go on to some other host offering that application.
Would you really want to compile something for a customer on an anonymous and >>untrusted machine?
First. Compiling something isn't the only use of this appliance.
Second. As already mentioned in the documentation this isn't for the CIA or for confidential data....at least not till more security concepts are in place....which again are largely understood problems and as such can be dealt with.
Third. To answer your question. This would largely depend on the paranoia/trust levels of the individual. In my humble opinion as software developers we generally need to depend on tools/libraries/code (open source and/or closed source) compiled by strangers leaving ourselves and our customers open to a plethora of potential backdoor entries and/or bugs.
That said stricter protocols could also be implemented to minimize risk of your data from being tampered with while it's on a host system. There're quite a few data validity authentication mechanisms already in place which could be potentially extended to this end.
To reiterate once again this is Proof Of Concept in it's current form. It's goal is to bring out a) to lay out all the major ingredients of this concept b) to bring out all potential areas of improvement for this concept. To that end I thank you again for spending time to comment on this appliance
Hopefully the above helps in some way.
Bye for now
Jeetu aka topcat
Message was edited by:
topcat