Closed 0x391F closed 3 years ago
Unfortunately this legacy feature was very much snake oil, as all files that were deleted by sandboxed programs while in operation were just deleted in a normal windows unsecure way.
For example when chrome & co save bookmarks they save the file as something.tmp and than delete bookmarks and rename the temp file to bookmarks.
Hence when you use the old "secure" delete function on the sandbox only the most recent bookmarks get properly erased while all the previous once stay on the disk untouched.
If you want data stored to a sandbox definitely gone, you need to locate the box into a container file, eider directly VeraCrypt or a windows .vhd/.vhdx and than securely erase the container after use.
That is why this feature is not and will not be included in a plus build.
What I could do at some point will be to offer automatic containerization of boxes, i.e. automated creation of a *.vhdx file and mounting int into the default sandbox root folder. With that I could add a secure erase the container feature as than it would be properly reliable.
I am not sure if sandboxie control which section on disk that it written to in this operation. From my understanding of hdd, when you write a new file using standard api, the disk would prority to write to lowest section first, which in the temp files case, there is a high chance that you would overwrite it if the temp files was in this lower sector. It could still miss these files though But that is for hdd, ssd is complete different, you could not read write to sector directly, the ssd chip control that at low level as it fake sector to windows driver. Each operation write to new block 128 kB (not sure the number). Only when no more new block then it recycle old block. Remove file destination on removal. Think like sector keep counting up until end. The virtual file could still left the trace as each write is new file end of zip file, just append at end of old file. And remove/redirect that extension on remove, overwrite. Those traces in high sector might left over The only correct way to secure delete is write to all empty space of the disk for both hdd, ssd
I would rather recommend use disk encryption for a partition and use sandboxie under that. As you do not know where those previos files on hdd without a deep scan, could be in the high but extremely slow sector. On ssd, you have to fully use the physical drive, like all partition c:, d: and hidden ones for booting, recovery. And you have to do +1
Hmm...How about disposable encrypt? Maybe Sandboxie could use disposable key (only storage in memory) to encrypt the vhdx file, when user delete contain files, delete the disposable key and vhdx file. Veracrypt maybe could do this.
But we need to inform users: once delete content, exit Sandboxie or restart/shutdown OS, the key will destruction, files in Sandboxie couldn't access or recovery anymore, don't storage any important files.
In widows, vhdx could not be encrypted on the host window. You would need to encrypt data, file inside the virtual disk. So you create vhdx file, mount to windows host, turn on encryption on that drive Set sandboxie to use that new drive for storage
👉 https://github.com/sandboxie-plus/Sandboxie/issues/591#issuecomment-1030290990
there is a new Triggers tab in the advanced options since v1.0.10 that will allow to specify commands to be run unboxed just before a box content gets deleted.
Sandboxie legacy build have a "Delete Command", users could choose how Sandboxie delete contents, they could use SDELETE/Eraser-5/Eraser-6 to avoid anyone recover deleted files.