Sandboxie-Plus v1.0.11

Perhaps it would. But then - as I see it - the editor wouldn't start at all, at least it couldn't be activated from within the sandbox. That would be contrary to my intentions. Even generating an error-message denying the start and me having to open the editor manually would be annoying at best.

No, I deliberately want to be able to activate the editor from within the sandbox, only that I need a way then to keep it from auto-shutting-down with the browser as the leader-program. So I could either not declare the browser a leader-program and run into problems with the box not auto-deleting correctly because of remnants of other processes - or - as I have chosen, make use of that option as intended? and declare the editor as a leader-program as well, thereby keeping the box from auto-deleting as long as the editor is still active but triggering auto-delete immediately after the editor is manually closed, too. Which is exactly what I want to happen.

 

@algol1 : I see. Thanks for the explanations.

Yes. For this reason I also have the browser as leader-program.

Sandboxie can be a quite sophisticated software.

 

Granted! Sometimes sophisticated is much better than overly simplistic!

 

Interesting, I didn't know about this story, or perhaps I forgot about it. But I also remember that certain companies tried to copy him, but those tools were way heavier, think of tools like GreenBorder, BufferZone and SafeSpace.

 

Since some versions of Sandboxie (classic x64) the template for the "Actual Window Manager" (Actual Tools) does not work anymore. I thought for a long time that it was due to the browsers own protection techniques, because Actual Window Manager stopped working in the browsers. But now I see that it no longer works for all windows in sandboxes.

Edit: The reason seems to be not a change in Sandboxie, but in the current version 8.14.6.1 of the Actual Window Manager. Up to version 8.14.5 it still works, since version 8.14.6.1 it does not. I hope David can adjust the template so that it works again.

Sandboxie classic x64 v5.55.11
Windows 7 x64
(But also on Windows 10 VM and there also with "plus 1.0.11")

 

That's weird, I remember about Actual Window Manager from back in the days. Looks like Sandboxie is blocking it somehow, hopefully David will be able to fix this. I have also asked him about fixing SpyShelter's ability to provide keystroke encryption for sandboxed processes, but he couldn't figure it out. KeyScrambler does work correctly with sandboxed processes. But I believe solving this is probably less complex since Actual Window Manager did work with older SBIE versions.

 

You really don't have to set firefox.exe as Leader program but doing so doesn't hurt you in any way.

Regarding being "completely sure that after terminating Firefox no other processes remain running in the sandbox", that's why you got the right corner of your right eye for. Sandboxie users are supposed to use the right eye to track the Red X and the dots and that's one of the ways to know whats going on in the sandbox.

Bo

 

Pete, you forgot something. You add exe's to allow not to forbid.

Bo

 

You knew the story and forgot it. Tzuk talk about this things in an interview in 2008. Over the years I posted the interview many times here and elsewhere. You probably heard the interview one of those times.

Bo

 

The reason seems to be not a change in Sandboxie, but in the current version 8.14.6.1 of the Actual Window Manager. Up to version 8.14.5 it still works, since version 8.14.6.1 it does not. I hope David can adjust the template so that it works again.

 

Here's something interesting that I saw when I unlocked my computer this morning, three Sandboxie icons in my taskbar. Anyone have any ideas why this happened?

 

I have one question Bo.
In one occasion when closing Firefox, I noticed that sandbox didn't autodelete (looking for red X as you described). I checked what was running and there were two MS processes running in sandbox. So I force closed sandbox. If this happens again I want to make changes to settings. Which in your opinion would be better to do:
1. adding Firefox to Leader programs
2. adding those processes to Lingering programs list
3. or both of the above?
BTW I use Classic version.
Thnx for you answer.

 

I think if this happens rarely, there is no need to use any of this settings. Also, remember, your AV or another security program you are using might interfere with the termination of all programs. By the way, you can set Sandboxie control to stay Always on top. You can set it up in View>Always on top. If I was in your situation and wanted to use this settings, I would probably choose Leader program.

In many of Sandboxie Plus threads people talk about settings and changes (which to me most of them are sacrilegious). I am going to use this post to talk real quick about the Always on top setting in Sandboxie. This is one Setting that did not come with the original Sandboxie, but was introduced by Curt. Years ago, don't recall exactly when, in a PM conversation I was having with Curt, I mentioned that it would be a good idea to have something like that for tracking issues like the one you are describing. I told him that it would be great to be able to set Sandboxie control to stay on top so when closing the browser we could see the behavior of the processes/programs running in the sandbox. Months later, he added the setting.

Bo

 

At the moment when this happened I did not have AV or other security software installed.
Thank you for describing Always on top option, which will be handy if I decide to try to troubleshoot this or any other problem.
For now I will add FF to Leader list and hope that this will prevent similar situation in future.

 

I think the point is that we (leader program users) not only want to know about the status of the box - we want things to be processed and taken care of automatically.

Apart from that Plus-users seemingly are no longer supposed to having their right eyes glued squinting at the systray-icon as that "red X" simply isn't there any more.

 

Indeed it doesn't. And I think it can help me to avoid situations as the one described e.g. in the meantime by Minimalist:

You know that I am not on good terms with the Red X and the dots in the way they are used as symbols in Sandboxie.
But even apart from this: By watching these symbols you can (only) control (watch) if something has gone wrong (= if a process is still running). With certain settings (like the definition of a leader program) you can (hopefully) prevent that something will go wrong.

Ah, I just see that algol1 has stated in the meantime more or less the same in other words:

Sorry that I must contradict a little bit here too. If desired by a user, he can also explicitly forbid the start of a program/exe in a sandbox:

David announced that it will be added in the Plus-version too: https://www.wilderssecurity.com/threads/sandboxie-plus-v1-0-11.444070/#post-3068223

 

Sacrilegious you say? Boy, I wasn't aware that some PC-security-tool might eventually achieve religion-status - even so that an outrage could be committed against the idol?!

 

True - but constant squinting at the tray indeed isn't my favorite course of action if I don't really have to!

 

When you see the red X, you know the sandbox is getting deleted. Nothing else is needed. From my point of view, anything else is pure fat.

By the way, Do you have an idea how long ago it was last time one of my sandboxes did not delete on closing of a sandboxed program? I know you don't know so I will tell you. It was so long ago that I cant remember but I can tell you that it probably was 3 or 4 years ago. So, this thing about wanting "things to be processed and taken care of automatically", is not something that has to be constantly monitored. If you have issues related to sandboxes not getting deleted, it is because of something that you are doing that doesnt go well with SBIE. And is for you to find out what that is. But you shouldn't be having deleting contents issues. I am going to repeat this again, for you only, last time I had the non issue of a sandbox not getting deleted was 3 or 4 years ago, and it was me who caused it. And I know what that was. I also know, you yourself can get up to that level of knowledge about SBIE

Nobody has to have their right eye glued to the SBIE icon. Monitoring the SBIE icon doesn't even require any thinking, it is so simple and its all done automatically. The original design was perfect. ~ OT Remarks Removed ~ My eyes are getting old, I don't have a good eyesight anymore, my eyesight now is bad, but still, I know whats happening in the sandbox and the best part about it is that I don't have to think about it or be distracted by a prompt or message.

Bo

 

Reminds me of the story behind Malwarebytes

 

Same thing here. I've absolutely no clue from what statement in my posts you feel entitled to conclude that I have "deleting contents issues" caused by my own inadequate use of Sbie which "I would have to find out" about myself. It is nice to hear "for me only, last time" that you had no deleting issues for 3-4 years now.

But I can assure you that in particular BECAUSE OF APPLYING THE PROPER SETTINGS, "Leader Programs" included, I don't see "deleting contents issues" on a regular basis on my system as well. Not sure though about the time period in years as from time to time the browser itself might freeze or hang due to suspicious web-activities and not properly close down at all. And thanks to @DavidXanatos those rare occasions can now be remedied instantly by applying his recently implemented "Terminator Hotkey".

 

I tried to find a solution today with the resource access monitor. I noticed that in the template the OpenIpcPath "*\BaseNamedObjects*\*_ServiceMapping" is no longer sufficient. There must be added a wildcard at the end now.

Now AWM works again in sandboxes, but the buttons are invisible. If you move the mouse over the places where they should be, you can see their tooltips. Clicking on them only works for the invisible "Always on top" button, for the others it does nothing.

Hopefully David will find a solution for this.

 

Wouldn't adding your editor to Start Restrictions achieve the same thing?
I couldn't work out how to get Firefox to open text files with an external program, so I used ZIP instead. I added 7zFM.exe into the Start Restrictions, and whenever Firefox opened a zip it launched 7zFM.exe in the same sandbox, and whichever program I closed first left the other open, until I finally closed the last program at which point the box was cleared.

I've been using Sandboxie for most if its life, and early on the recommendation was always to limit the programs that could run in a sandbox, the intention being that even if you ended up on a dodgy web page with a drive-by download, it wouldn't be able to run. Now browsers have come a long way since then, and I'm not sure that's really a risk (without a prompt at least), but that ideology has meant I haven't had to worry about leader or lingering programs since.

The other option you have of course - if you're using Plus - is to use 'BreakoutProcess=editor.exe', which would open your editor outside the sandbox. You'd only want to do that if you trusted the content that you were opening from the browser, although you could subsequently sandbox that process with a Forced Program box; it would mean however that the editor would always be sandboxed, unless of course you created a hard link to the editor and Forced that "program" instead.

 

Hi @DavidXanatos,

During testing, I was adding and removing programs from Start Restrictions and noticed that if you remove a program it actually removes two from the GUI, although when you click apply one is reinstated so just a cosmetic issue really.

 

Not quite sure what you mean by that. I must confess I'm not really familiar with Start Restrictions and the proper use of it.

As I've interpreted this feature so far entering the editor there would either prohibit it from running in this sandbox at all - which would be the complete opposite from my intention to being able processing text-files encountered or downloaded by the browser in the editor within the "realm" of the browser - or if I explicitly allow it to run in the box simultaneously this would
1) prohibit the browser from starting any other child-processes within that box (a video-player perhaps?) and
2) I would be thrown back to the mishap-situation from the early days as described above that my text - as preserved in the editor - would still be gone when the latter one would be force-closed by exiting or crashing the browser.

Furthermore when removing the browser as a leader-process - wouldn't the box be then kept from auto-deleting as long as any botched or hanging child-process was still active in there?

As I see it Leader-Processes are declared for a very good reason - which is to tell Sbie that they should take precedence over any remnants or child-processes I wouldn't possibly even be aware of still being active in that box. And because I have absolutely no intention of checking any residual contents of the box each and every time the browser would close down the Leader-Process-setting will take care of exactly that problem.

Now to further specifically exclude the editor - NOT from being started and used within that box - but ONLY from FORCE-CLOSURE by the browser it is the easiest and safest way to enter it as a leader process as well whereas ANY OTHER remnant- or child-processes would be considered as "lingering" at the same time and therefore being forcefully closed with the browser (or editor - whichever is last) so that the box can be successfully auto-deleted without being blocked by OS-open files or processes.