Maybe this option exists, but I'm looking around the Start/Run options, and I'd like to ONLY disallow objects in the sandbox. Now it looks like this will occur if I also use a white list, but I really don't want to restrict any software already on my computer... I just want to restrict executables from the sandbox.
I tried to use SRP for this, but Sandboxie is apparently transparent to SRP... blocking c;\sandbox\ does nothing, as SRP appears to think the processes are launched from the temp folder (or wherever else they are redirected from). I'm guessing because SRP is just running in user mode, and the sandboxie driver is doing all the magic at a lower level.
Oddly enough, Faronics AE works with it, but oddly enough I can't run purely with a blacklist.
I know running just a blacklist is not as secure as whitelisting (I myself run SRP in a rather locked down config), but I'm trying to set regular users up with stronger protection... one big security hole is the ability of foreign software to gain read access, and I'm trying to close that hole in a way that makes it easy for a regular user. If they want to open up word, adobe reader, or whatever program they desire, I still want them to be able to do that. I don't want anything outside the system executing from the sandbox though.
Is this currently possible? If not, is this something you might consider implementing in the future?
Disallow sandboxed files from executing
Experiment with this:
Sandbox Settings > Restrictions > Start/Run Access
On versions 3.51:
Click the "Add Program" button > put * ( a single star) in the "Select or enter a program" box" > OK
This will put '*.exe' in the large box
(read the note at the bottom of that window. * is a wild card character and will match any name)
OK your way out.
If your version doesn't have the "Add Program" button and the "Select or enter a program" box, use the "Edit/Add" button and put
*.exe
in the window.
"Run Sandboxed" a program like Notepad - that exists outside of that sandbox - and choose that sandbox.
(This is just to create a directory structure inside of the sandbox, for the tests that follow)
Copy some .exe files into that sandbox using an unsandboxed Windows Explorer.
Try running the .exe files that are inside the sandbox.
I've never tried adding other executables, like *.com
I don't know how that would work out.
Sandbox Settings > Restrictions > Start/Run Access
On versions 3.51:
Click the "Add Program" button > put * ( a single star) in the "Select or enter a program" box" > OK
This will put '*.exe' in the large box
(read the note at the bottom of that window. * is a wild card character and will match any name)
OK your way out.
If your version doesn't have the "Add Program" button and the "Select or enter a program" box, use the "Edit/Add" button and put
*.exe
in the window.
"Run Sandboxed" a program like Notepad - that exists outside of that sandbox - and choose that sandbox.
(This is just to create a directory structure inside of the sandbox, for the tests that follow)
Copy some .exe files into that sandbox using an unsandboxed Windows Explorer.
Try running the .exe files that are inside the sandbox.
I've never tried adding other executables, like *.com
I don't know how that would work out.
Paul
Win 10 Home 64-bit (w/admin rights) - Zone Alarm Pro Firewall, MalwareBytes Premium A/V, Cyberfox, Thunderbird
Sandboxie user since March 2007
Win 10 Home 64-bit (w/admin rights) - Zone Alarm Pro Firewall, MalwareBytes Premium A/V, Cyberfox, Thunderbird
Sandboxie user since March 2007
-
AgentSmith
that works for .exe's
Thanks! That seemed to work for .exe's. Sadly, it didn't work for .com files, or any other type of file.. it is better than nothing..
I also figured out that for a regular home user, who is running XP as an administrator, I still could use SRP (and just exempt administrator). Esentially, SRP will only apply to sandboxie if it is using drop my rights. Using a standard SRP setup, I can whitelist program files and windows.. Any drive by execution can't write to these folders.. The sandboxed process isn't exempt from SRP because it is not run as an admin, like the user's regular processes.
While this will blacklist more than just the items in the sandbox, it should still allow the user to run everything they need (word, adobe reader, etc) and still stop any other forms drive by malware.
I'm at a loss for a more complete solution with windows vista/7 though. Since you are not an administrator by default, if you implement SRP or Applocker, then SRP applies to the user even when they are not in the sandbox. I can't use the above trick to have SRP only apply to the sandbox or sandboxed processes.
I could turn off UAC completely, but then in some ways I'd be making it less secure. Then again, they'd be in the same situation as the XP users.
Have any clever tricks that might let a more comprehensive execution blocker that ONLY applies to the sandboxed files or processes?
I also figured out that for a regular home user, who is running XP as an administrator, I still could use SRP (and just exempt administrator). Esentially, SRP will only apply to sandboxie if it is using drop my rights. Using a standard SRP setup, I can whitelist program files and windows.. Any drive by execution can't write to these folders.. The sandboxed process isn't exempt from SRP because it is not run as an admin, like the user's regular processes.
While this will blacklist more than just the items in the sandbox, it should still allow the user to run everything they need (word, adobe reader, etc) and still stop any other forms drive by malware.
I'm at a loss for a more complete solution with windows vista/7 though. Since you are not an administrator by default, if you implement SRP or Applocker, then SRP applies to the user even when they are not in the sandbox. I can't use the above trick to have SRP only apply to the sandbox or sandboxed processes.
I could turn off UAC completely, but then in some ways I'd be making it less secure. Then again, they'd be in the same situation as the XP users.
Have any clever tricks that might let a more comprehensive execution blocker that ONLY applies to the sandboxed files or processes?
finally found my login again...
Is there any intention to improve the anti-executable portion of the code? Sandboxie is pretty airtight for writes, but reads have always been a threat.
If Sandboxie had the capability of not running anything downloaded into the sandbox, it would pretty much be a perfect security measure.
Is there any intention to improve the anti-executable portion of the code? Sandboxie is pretty airtight for writes, but reads have always been a threat.
If Sandboxie had the capability of not running anything downloaded into the sandbox, it would pretty much be a perfect security measure.
Similar to what I suggested in the recent cmd.exe thread, if you really don't want something to execute, you can try a ClosedFilePath (aka Blocked Access): ClosedFilePath=*.comAgentSmith wrote:Have any clever tricks that might let a more comprehensive execution blocker that ONLY applies to the sandboxed files or processes?
I can't guarantee that this won't impact any of your other sandboxed programs, but I would think that if you're going to block execution of .com files, taking it a step further and blocking read/write access probably won't make things any worse.
If you want to take a more gentle approach, and simply prevent new .com files from being created and run in the sandbox, you can use a ReadFilePath (aka Read-Only Access) instead: ReadFilePath=*.com
This will still allow existing .com files on your real system to execute sandboxed.
That is a clever trick... I personally hadn't thought of doing that, and I can see how it could be effective.
Unfortunately, a lot of malware seems to learn how to execute without proper extensions. I often see .tmp files running in explorer, and are usually a form of executable (probably natively an EXE)...
I think this is a popular trick to get around the A/V's...
Unfortunately, a lot of malware seems to learn how to execute without proper extensions. I often see .tmp files running in explorer, and are usually a form of executable (probably natively an EXE)...
I think this is a popular trick to get around the A/V's...
I actually got this to work..
I have found that while blacklisting C:\Sadnbox\* does NOT work with SRP... It works with Applocker. I'm guessing that this is because SRP operates as a user level process, while applocker runs at kernel mode.
In other words, if you have Windows 7 Pro or Ultimate, you can use gepdit.msc to make an Applocker path rule that disallows anything in C:\Sandbox\* . You have to do this for executables, windows installer files, scripts and DLL's (you have to check a box in applocker properties to allow for dll filtering).
This works GREAT, and nothing that is saved to the sandbox will execute. You can still use all the programs that exist outside the sandbox (excel, adobe reader, etc)...
The benefit of this is obviously that no drive by malware will be able to launch and transfer any of your data...
In other words, if you have Windows 7 Pro or Ultimate, you can use gepdit.msc to make an Applocker path rule that disallows anything in C:\Sandbox\* . You have to do this for executables, windows installer files, scripts and DLL's (you have to check a box in applocker properties to allow for dll filtering).
This works GREAT, and nothing that is saved to the sandbox will execute. You can still use all the programs that exist outside the sandbox (excel, adobe reader, etc)...
The benefit of this is obviously that no drive by malware will be able to launch and transfer any of your data...
Who is online
Users browsing this forum: No registered users and 1 guest
