Sandboxie Plus (Sbie fork)

Sandboxie is finally Open Source

I have uploaded the sources, as released by Sophos today, to GitHub: https://github.com/DavidXanatos/Sandboxie
and fixed an issue that prevented the sources from correctly building (encoding on SbieControl.rc was messed up).

Cheers
David X.

 

Thanks

 

This is the first non original release, it fixes the the issue: #1 and adds some new debug capabilities.

Download: https://github.com/DavidXanatos/Sandboxie/releases/tag/v5.40.1

Change Log:
Added

• "Other" type for the Resource Access Monitor
  -- added call to StartService to the logged Resources

Fixed

• fixed "Windows Installer Service could not be accessed" that got introduced with Windows 1903

 

Windows 7 without kb4474419

https://img.techpowerup.org/200410/sb.jpg

 

Just a heads up. The 64 bit release is mislabeled as 4.50.1: SandboxieInstall64-v4.50.1.exe

And one off-topic. Will any of your changes affect
the version for XP that you kindly posted in another thread?

 

This issue seams to occur only on Windows 7 32-bit and to be already present in the SandboxieInstall32-533-6.exe Sophos build.
I will take a look how to fix that.

Mean while could you please test what is the last Sandboxie build that worked on your machine.

 

Yes, 64 bit release is mislabeled as 4.50.1: SandboxieInstall64-v4.50.1.exe

 

Thanks... type fixed.

As long as I only fix win 10 specific issues there is no need to release a new XP build.
For the long term I'm looking to make the default 32 bit build WinXP compatible.

 

Um, does 5.40.x over install 5.33.x forwards and backwards like pre 5.40.x.

 

Excellent! And please keep up the good work!!!

 

Yea you should be able to install everything over everything
If I ever change something that would break that be assured I would add a big fat red warming in the release notes.

 

Thanks!
typo fixed

 

Please excuse my ignorance but, what's to stop someone with nefarious intentions from weakening the sandbox?

 

So what's the @DavidXanatos Sandboxie roadmap looking like? You've been itching to get your hands on the source code for a while now so that you can "dive in", and outside of bug fixes like the MSI installer one (congrats on your first bug fix, and lol it takes you less then a day to fix.), I'm sure you've been wanting to add/do things to SB to make it more personalized to your liking, anything you care to share about it? Or is it all "up in the air" right now/not sure yet/"can't reveal my secrets just yet" sort of deal.

 

The sandbox, you are not supposed to be able to weaken it from the inside.
And if you already have control over the system than there is no more a point in attacking the sandbox as you are already out.

 

The plan is long, but not very well formulated so I'll just throw in here all the ideas more or less unsorted and make a proper Roadmap out of it later on.

Data protection:
Sandboxie is great to protect the system from malicious modifications but with default configuration it does not protect user data from being accessed and exfiltrated.
Also it dos not protect the users privacy in therms of his user name and or unique hardware information like MAC-addresses or disk serial numbers, etc...

So I would like to make programs inside the sandbox see an empty user account just called user without access to the actual users profile data, ideally when creating a sandbox the user would choose if its a regular sandbox like currently or an anonymous sandbox without personal data.
For hardware information that is a subject for later...

Networking:
Sandboxie allows to restrict network access only through the ini file.
Here my threat model is more privacy violating applications which don't use malware tactics, i.e. programs with unwanted Telemetry baked in.
Hence I would like to add a better control over the sand boxed application's network connectivity.
Definitely some easily accessible switch for each sandbox determining if the app inside can access the LAN, WAN or neither and not to far from it exception lists per process.

On one hand why not a full blown application firewall but than one can just use a 3rd party application firewall, not sure about the right balance between functionality for those that only have the windows firewall and redundancy for those with more advanced tools.

Application Virtualization:
Sandboxie due to the basic version being restricted to one sandbox at a time, never was much about using multiple sandboxes.
I would like to develop Sandboxie more towards a software packeting tool like the old Altiris SVS was, i.e. you install your software into a set of separated boxes and when you exchange your laptop or re install your Windows because MSFT broke it again, you just copy your box repo onto the new system and continue where you left of on the old one.

One could even think about a network based synchronization feature to use the same set of applications on multiple devices, and I would implement is on a P2P basis such that you don't necessarily need a home server, although one of this QNap or Synology boxes sure might be nice.

Complete UI Rebuild:
No, No, don't worry nothing like this atrocious win 10 modern UI abomination, but something more maintainable and better looking than the current plain C with Win-Forms, something with the esthetics of windows 7 or Classic XP.
If you need an idea what UI paradigms I cherish take a look on my Task Explorer.

Not sure if I will go with C++ and Qt again, or may be I try .NET C#, but there will be a completely new UI with a ton of easily accessible options, no more messing around with ini files.

Better Analysis Infrastructure:
Sandboxie hooks a many API calls, not all of them but a ton, and what output do we get, some Error Messages and a very basic Resource Access Monitor.
I think we can do better, much better in fact, a full verbose log of all the hooked API calls and parameters, imagine ProcMon.exe on steroids, something along the lines of WinAPIOverride. I think that would be extremely useful in resolving compatibility issues.
What we would also need would be the ability to create permissive testboxes i.e. just instrument/hook a process but don't isolate it from the system. With that comparing an applications traces from a sandbox and a testbox on the same system would make finding the calls where something went wrong child's play.

On this note I think a tool that pretty much captures all API calls might be very useful for ReactOS/WINE developers, actually why not set out to add official ReactOS support to sandboxie.

Plugins or Scripting:
Sandboxie implements many hard-coded workarounds for various Applications for example search for "chrome" in the code 133 results...
IMHO we should be able to implement workarounds ideally as scripts or at least as binary plugins, such that whenever something needs fixing its not necessary to rebuild and reinstall the entire project.

Now, booth options would need in principle a complete rework of the SbieDLL. Binary plugins are definitely doable with decent performance, scripting that's a different can of worms.

Limited Driver Support:
And last something to dream about...
When playing around with WINE (which is not an emulator) I noticed that I can there in fact load a driver as long as it does not need hardware access and generally doesn't do to much.
WINE spins up a User Mode process with the necessary API for a windows driver to load and do something. That may be useful for some use cases.
Now I have no idea how much work it would be to back port that to windows and plug it into the Sandboxie infrastructure, but it definitely would be a lot of fun.
Muhahahahahaha...



That's the things I remember I thought about of the top of my head, probably I missed one or two more...

 

This probably has me the most excited (but also scared) because there is so much lacking with Sandboxie UI as it stands now, like how you have to dig through folders in Windows Explorer instead of being able to drag 'n drop directly from the SB window itself, etc. and just the general lack of info it tells you, and how programs/files&folders are split into 2 different views... very annoying.

But don't go with QT, its a bloated laggy mess compared to something in like C++, you gotta keep SB lean and low in resources as much a possible.

 

Well that kind of applies to .NET even more.

And C++ with MFC is a pain to work with.

So a new UI will need some sort of framework that makes the work easy.

 

Hi
Are you imagining Developer/s with nefarious intentions would publish to unsuspecting Sandboxie users - forks n'or releases to further the Developers nefarious purposes?

 

Sorry, I guess I didn't word the question correctly...
Let's say there's a Malware-Developer who wanted to screw with Sandboxie to weaken it so that they could write malware that could infect the OS...what's to stop him?
For example what if DavidXanatos was a bad guy? (I'm sure he's a lovely person)

 

You either trust a developer or you don't. I mean, if you trust DavidXanatos and like his software, go ahead and install it. If you don't trust him, well, then don't install his software.

 

Yeah, .NET is literally trash tier for performance and being "light", that should be your last option... And unfortunately I don't have any "easy frameworks" suggestions for you on this matter.

 

I switched to Insider build 19603.1000 and Opera in Sandboxie has become about four times slower to open than it was in release build 1909. Nothing else was changed or added to the browser. I may go back to 1909 the hard way, ie: a clean install, simply because it's almost night and day the way Sandboxie behaves in this Fast Ring build. Currently at 5.33.6. Haven't tried the new 5.40.1 yet, maybe out of a sense of nostalgia.

 

If a adversary gets you to install any application with admin rights he already won, period, nothing more to do.

Purposefully weakening security software is something IMHO only a state level adversary would have a reasonable interest in doing. As the goal of an intelligence agency is not to hack everyone as that would draw attention, their aim is to be able to hack everyone without actually doing this unless someone is particularly interesting.

 

Code review by other developers before any commit is accepted.