I sandboxed IE7. I then went to a site (SysInternals) and downloaded a file. Because no indication is shown that an app is sandboxed (like a colored border or something in the titlebar), I forgot the web brower was sandboxed. After download a file (Process Explorer) from the site, I couldn’t find it where I said to save it. Then I remembered that I had sandboxed the web browser. I noticed that if I did the download again that the file was already listed (in the sandbox) from the prior download. That is, when I had exited the web browser, the file that had been virtualized in the sandbox was still listed in the next we browsing session. Apparently the sandbox does not get cleaned out when the sandboxed application is exited. Very sloppy.
The path where the downloaded files went into was:
There is no differentiation between multiple instances of that application. That is, if I start N copies of the same app, they all share the same “virtual” (redirection) folder. Not only is the virtual store not actually virtual (it’s on the same disk and in the same partition as the real OS without any real separation), and not only do multiple instances of the sandboxed application share the same sandboxing folder under C:\Sandbox (which means there is no isolation between the sandboxed apps), but there is also no cleanup when that sandbox is no longer applicable (to clean the virtual folders which are actually accesible by the user and still pose a threat).
In Sandboxie, you could have multiple instances of the same app share the same sandbox. You could even have multiple different apps share a common sandbox. Or you could have each instance of an app in its own sandbox to isolation any collusion between them regarding malware behavior. But however your shared or not, the sandbox could be cleaned out so no remnants lingered into the next app that reused the same sandbox. As it is now, the virtual store for the sandbox isn’t hidden to user processes because a kernel-level file driver isn’t hiding the virtualized paths. Any user downloading a file in a sandboxed application can still access and execute that downloaded file just by knowing about C:\Sandbox (rather easy to discover) or by doing a file search on it.
The only good protection that sandboxing gives might actually be a separate function of the Defense+ module, which is restricting privileges on the untrusted process by assigning an LUA token to it and its child processes. I could get that with SysInternals psexec or with DropMyRights except those don’t handle child processes that are started separately of the shortcut used to run psexec or dropmyrights; for example, clicking on a URL link in an e-mail starts a child process to load the web browser that wouldn’t have its privileges restricted under a LUA token. Online Armor has its Run Safer feature that can enforce reduced privileges on a process regardless of how it got started. I figured with Comodo’s sandboxing that an additional layer of protection beyond reducing privileges would be available but it doesn’t look like very good sandboxing so it isn’t a strong argument against other security product that don’t have sandboxing to qualify Comodo’s product over others.
Guess I was expecting more than just redirects to alternate folders for sandboxing or, at least, decent cleanup of the sandbox with the sandboxed app was exited. I’m really not interested in malware that supposedly got sandboxed (it download but couldn’t execute due to reduced privileges) but lingers around to have my anti-virus program throw up alerts on what should have been discarded after the sandboxed app was exited.