Can advanced users, who are testing this on a non-production system, please try to run/install as many applications as automatically sandboxed (with full virtualization checked) to see what dangers there may be for ordinary users to accidentally select this option?
What I think is going to be very important for this Beta testing period is testing out this new automatic full-sandboxing. Please do whatever you can to break it and find out if installing applications in it can damage the system in some way. I’d really like to find out how suitable it really is for everyday use.
Please test it against all sorts of applications, including those which will automatically start when the system starts up. This is where we expect the majority of problems to come from, so I’d love to see whether it can actually hurt a system when those types of applications (although we need to make sure it works well with all other sorts as well).
Please test it and let me know what sort of problems you run into. I’d really appreciate any feedback anyone has.
It’s very important that we ascertain what kind of negative consequences might arise from enabling automatic full virtualization for unknown applications.
depends on the results of the testing. I doubt it will be in the final but maybe in a future version. egemen wants to see how testing goes with the advanced users.
In auto full virtualization anything autosandboxed & sandboxed through elevated rights popup will be automatically deleted, right?
i.e autosandbox - suppose I have a file on the desktop. I run it & it is autosandboxed & will be there in the unrecognized files lists. After restart unrecognized files lists will be automatically deleted & the file will not be there on the desktop, m I right?
Elevated Rights popup - Suppose I have an installer on the desktop. I run it & get elevated rights popup & I hit sandbox. After restart stuffs installed by the installer will not be there but the installer on the desktop will be there, m I right?
RE virtualised programs accessing the internet and comms between virtual and non-virtualised programs
You can use HIPS & FW to restrict this for virtualised programs if you wish. Please see the new FAQ in stickies.
If you install a program in the sandbox, that installed instance can have distinct HIPS and FW rules from the non-virtualised instance. Just remember to use the VTroot path to the executable in the rule.
So you can control internet comms using FW
And COM and interprocess coms using HIPS rules
Probably sockets coms using firewall via port restrictions
execution using HIPS rules
So you can I think prevent most coms-based leaks from virtuals to non-virtual and from virtual to the intern et.
AFAIK unfortunately no ability to make pairwise* rules yet, rules that depend on whether coms is from progs running virtual to progs running non-virtual, or virtual to virtual. Also rules have to be on an installed instance not a virtualisation run status basis. (*Well access and protection division and execution control might give you some abilities here). Also no specific virtual NW zone yet (because sandbox has no separate IP), and you need to remember not to use HIPS rules that go against the idea of virtualisation.
But it’s a start… and means that you can stop leaks from the CIS sandbox, if not with as fine a grained and convenient control as you would like.
Helps CIS compete with sandboxie, which does have options to cotrol such leaks.
[edited]
■■■ and JohnDoe install and function well allowing you to anonymise internet comms for all apps that can take a port setting.
Trustconnect does not install, and I can find no way of automatically using an external TrustConnect connection in KIosk (ie switching it on only while you are in the Kiosk). Of course you could maually switch your home network to public in CIS while you use the Kiosk, that would invoke TrustConnect I think.
I like the way it works in terms of protecting the actual computer from changes, but if it is not monitored by the firewall at all, and can copy data from the actual computer, I believe it is a very dangerous setting after all.
If only it was monitored by the firewall I wouldn’t be too worried.
No AFAIK by default all outbound connections are allowed
And virtualised processes can read any data in the normal computer
But, you can use the firewall to control this. Seems to be active.
It’s the normal IS config settings that are allowing outbound access
You appear to be a able to set separate FW and HIPS (if enabled) rules for apps stored in VTRoot. Not experimented much with this so don’t know how far it goes.
So you could set a fairly generic rule I suppose for paths starting C:\VTroot. A sort of all virtualised executables rule.
Interestingly in general it appears that virtual apps defaults are controlled by HIPS rules not BB - remember I could not screen snip. With the new BB I could have done!
Currently I’m using sandboxie (the best in my opinion), and I’m very interested in this sobject, cause before replacing it the basical thing to know is how much effective is CIS 6 virtual environment (autosandbox fully virtualized, manual sandbox, Kiosk)…only if tests will confirm that CIS sandbox = sandboxie (i.e. NO files dropped into the system, malwares can’t bypass it), I will evaluate this change… 8)
