Recover Sandboxed Files Security Enhancement

[dlguild]

Currently, to ensure that files I recover from the sandbox are safe I follow the following procedure:

1. Using the Sandboxie Explorer, I select (right click) the files I would like to recover and invoke my virus scanner.

2. Assuming the virus scanner indicates all is well, I switch to the Sandboxie 'Recover Files' function and execute the recovery.

While this process is not overly difficult or time consuming, it is easy to forget to do it and almost impossible to get other family members to follow the procedure.

It would be very useful if Sandboxie could be set to automatically invoke an installed virus scanner during the recovery process. Perhaps this could be done through an enhancement to the sandboxie.ini file by providing an entry containing the necessary information relating to the installed anti virus software (if any) on the system. Or by a registry entry similar to the "DeleteCommand" used by some for secure deletion. Even an option to scan the entire sandbox (or the recoverable portion thereof) prior to or during file recovery would be acceptable (although for some the sandbox may contain a lot of stuff).

This would add another layer of security to an already great security product.

Dan

[SnDPhoenix]

That is a good idea, as a matter of fact, alot of other software out there has an option for specifying a command to scan a file using your anti-virus, for example, WinRar, a popular (and the best) archiving utility has an option for specifying the path and command to/of your antivirus, that way before a archive is extracted, it is scanned first to be safe, heres the problem though, One; tzuk would need and/or want to introduce this function as well as find a successful way of incorporating the setting into the program, and Two; you would need to know a) the path to the exe of your antivirus, (and you'd have to make sure you choose the correct exe file seeing as antiviruses always have a lot of exe files) b) you'd need to know exactly the command that is executed when you right click a file and select "Scan for viruses" (or something along those lines).

[dlguild]

b) you'd need to know exactly the command that is executed when you right click a file and select "Scan for viruses"

You are right of course. Probably would benefit the technically savvy types the most. I was thinking of something similar to the "deleteCommand" registry key which some have used (including me) to implement secure deletion. I agree that it would be a royal pain for tzuk to have to investigate all the various AV products to determine their individual command requirements. Let the user sort it out, at least initially.

At the moment version 2.86 does not allow you to right click on the file names in the recovery window to get to the context menu. Even this would be an improvement.

[tzuk]

The security center in Windows XP SP 2 recognizes anti-virus software (or perhaps they are supposed to register with the security center). So it may have this information, I'll see what I can find about it. I'm also making a note to myself about right-clicking in the recovery window.

[dlguild]

Thanks tzuk.

For future reference, I looked into this a bit. From what I gather, Windows XP SP 2 tracks Antivirus information in its WMI database, which is in turn read by the Windows Security Center. XP SP 2 also contains a program, WBEMTEST.EXE, that allows you to view, add and edit the values in the WMI. MS article http://msdn.microsoft.com/library/defau ... t_page.asp might be helpful. PC Magazine wrote an article about this, http://www.pcmag.com/article2/0,1759,1639276,00.asp, in which they consider access to the WMI database to be a security hole in Windows. Microsoft may have closed it up in Vista. WBEMTEST.EXE still works on my fully patched XP machine.

On the Kaspersky forum, the command line information for their product is readily available as a lot of users are using AV in conjunction with download managers, etc. I suspect the same must be true of other AV software products as well. Letting the users come up with the needed command line might be a more universal solution (not operating system dependent) than trying to do so programmatically.