Sandboxie Acquired by Invincea

"Component Package Support Server"

Windows is able to deliver Updates for Firefox, so with 72.0 you are triggered to install 72.0.1 security update.

 

Hi @Brummelchen
So, "Component Package Support Server" is related to?
So, I should not see "Code:" with 72.0.1 on-board?

Code:

SBIE1308 Program cannot start due to restrictions - CompPkgSrv.exe [Firefox]
SBIE2222 To add the program to Start/Run Access Restrictions, please double-click on this message line
SBIE2314 Canceling process CompPkgSrv.exe

Um, by "Windows is able to deliver Updates for Firefox". You mean Windows Update is able....?

 

I wouldn't take him too seriously, because he still seems to think that if the Chrome and Firefox sandbox are bypassed, Sandboxie will not be able to protect any longer. So seems like he doesn't understand what Sandboxie is about.

So are you saying that you can block access to all folders except certain ones? So for example, if you have a parent folder with 10 child folders, is there a way to allow access to only 1 of those child folders?

 

i wrote - THIS is windows

since firefox 68 - to read the release notes here in this forum
https://www.wilderssecurity.com/threads/new-firefox-browser-version-released.361562/

in special this one
https://www.wilderssecurity.com/thr...-version-released.361562/page-94#post-2839261
lead to
https://www.mozilla.org/en-US/firefox/68.0/releasenotes/

BITS is present in Windows 7/8/10.

do not touch it!

another hint

i am not sure what mozilla changed for firefox 72.0 that it appear in your box. could also using external certs
https://www.mozilla.org/en-US/firefox/72.0/releasenotes/

 

Sorry, I'm not following your comments.
Firefox downloads and updates when Firefox is closed.... without Firefox automatic updates?

Thanks anyway
Regards w Respect

 

Yes, I'm aware re Windows Background Intelligent Transfer Service, or BITS.
No, I'm not aware why my Firefox sandbox recently started throwing >

Code:

SBIE1308 Program cannot start due to restrictions - CompPkgSrv.exe [Firefox]
SBIE2222 To add the program to Start/Run Access Restrictions, please double-click on this message line
SBIE2314 Canceling process CompPkgSrv.exe

When my Chrome sandbox threw BITS messages. I unchecked Drop Rights.
Maybe, I need to test my Firefox sandbox with Drop Rights unchecked?

No worries ... HideMessage works.

Code:

SbieCtrl_HideMessage=2222,CompPkgSrv.exe [Firefox]
SbieCtrl_HideMessage=1308,CompPkgSrv.exe [Firefox]
SbieCtrl_HideMessage=2314,CompPkgSrv.exe

Just head scratch why my Firefox sandbox recently started prompting SBIE1308.

Edit: with Drop Rights unchecked ... my Firefox sandbox still prompts SBIE1308.

 

simple as that - it is NOT designed to run in sandboxie. it also makes no sense to run in sandboxie to load updates. updates are mandatory and vital and not just for fun in the box where the cause issues or wont work.

 

Um, if you're speaking to me. I do not install Firefox updates inside my Firefox sandbox.

 

@bjm_, perhaps you can try setting this preference: app.update.BITS.enabled to false.

I haven't used that preference since mid November after I created a new Firefox profile, but I used it before without any bad consequences. You can try the preference while sandboxed, if after testing it you are not being bothered anymore with the message, then set it up outside the sandbox.

You could also create a policy to keep Firefox from checking for updates. If you like doing this, I ll make it easy for you and send you via PM the file and folder you put inside your Firefox installation. Perhaps this would get rid of this annoyance for good for you.

Bo

 

Hmm, just checked and my app.update.BITS.enabled is already set to false.

Hmm, so there's a way to turn off Firefox automatic checks for update?

Just head scratch with HIdeMessage=1308-2314-2222 removed. I get SBIE1308-2314-2222 CompPkgSrv.exe message in Firefox Safe Mode and even in new default Firefox profile.

 

Yes, there is a way, works great and easy. Look at the 2 pictures below.





Right now I have dinner but afterward I ll tell you what to do if you want to disable Firefox updates. And I ll PM you the file and send you pictures so you know what to do. Confirm if you like me to do this.

Bo

 

Yeah, I'm open to see whats what.....no rush....at your convenience. Thanks

 

bjm, check your PMs.

Bo

 

Not with a single rule. Yet if you are willing to define rules for subfolders as well you can manage exceptions.

Eg if you make global rules (or via a template which you call globally - which is what I suggest but I can't exactly recall why I found that to work better at this particular moment)

[GlobalSettings]
Template=GenericRules

[Template_GenericRules]
ClosedFilePath=!<ProgramsToAllowToRoot>,C:\Root
ClosedFilePath=C:\Root\01
ClosedFilePath=C:\Root\02
ClosedFilePath=C:\Root\03
ClosedFilePath=C:\Root\04
ClosedFilePath=!<ProgramsToAllowToRoot5>,C:\Root\05
ClosedFilePath=C:\Root\06
ClosedFilePath=C:\Root\07
ClosedFilePath=C:\Root\08
ClosedFilePath=C:\Root\09
ClosedFilePath=C:\Root\10
ProcessGroup=<ProgramsToAllowToRoot>,1.exe,2.exe,3.exe
ProcessGroup=<ProgramsToAllowToRoot5>,2.exe

results in Only those programs added here (or in any other box via the same group)
ProcessGroup=<ProgramsToAllowToRoot>,1.exe,2.exe,3.exe
being able to access C:\Root
Then again
ProcessGroup=<ProgramsToAllowToRoot5>,2.exe
These rules combined mean 1.exe,2.exe,3.exe can read C:\Root
Then only 2.exe can also read C:\Root\05

It works better with some static(ish) data layouts and it's not easy. I also don't know how you might accomplish the same via the GUI. I gave up using the GUI for most stuff early on because the rules made much more sense when created and applied manually.

This is, in part, why I revamped my own drive layouts and came up with similar naming schemes allowing the use of wildcards across drives for some things to reduce the need of relying on 'redundant rules' and simply allowed drive exceptions as my primary gateway.

There are some things to keep in mind, foremost among them is that unless a wildcard is already used, SBIE adds its own at the end of the rule. So, most noticeably, in a numerical setting this could result in unwanted allowances but also applies to named folders. To continue this example,
ClosedFilePath=!<ProgramsToAllowToRoot5>,C:\Root\05
also allows anything existing under <ProgramsToAllowToRoot5> to also read from folders such as C:\Root\050 etc or even C:\Root\0500 or even C;\Root\05A (anything in between and more) if they exist. You'll have to use your brain a bit while creating your rules to check for potential [unwanted] collisions.

Another thing worth noting is that while in my example I created the 'ProcessGroup=' under the GenericRules area, you do not have to do so. They can be added under each box as well.

eg if you want to allow 1.exe to read C:\Root then you could add it there instead
[Box 1]
ProcessGroup=<ProgramsToAllowToRoot>,1.exe

[Box 2]
ProcessGroup=<ProgramsToAllowToRoot>,2.exe
ProcessGroup=<ProgramsToAllowToRoot5>,2.exe

[Box 3]
ProcessGroup=<ProgramsToAllowToRoot>,3.exe

but I always found it easier to keep the 'drive gates' I used all in one place so I generally used the GenericRules I had. There are other options, like creating extra restrictions 'per box' where you allowed an exception elsewhere but that always seemed even more wasteful and complex to me except in particular cases. That may just be because I overhauled my entire storage layout to reflect my setup though.
I also had (mostly) strict launch rules so while firefox.exe could start in box 10 nothing named firefox.exe could start in box 2. As such I didn't see much need to limit them per box and kept my rules 'close together' for quicker reviews and edits. It may be worth keeping the ProcessGroups to each box if your own setup doesn't make use of start/run limits as an extra precaution.

I expect I've made mistakes or missed something that seemed rather obvious in my inebriated state so I apologize in advance for that which I messed up on.

 

Hello,

just a general question. I've updated Sandboxie to the latest 5.33.1 version on my laptop (which is not super important to me) and it seems fine (with Windows 10 v1903 still).

But I'm still running the old 5.31.2 version which is still "registered and activated" on my main desktop PC (also still on Windows 10 v1903). Windows is bugging me about updating to v1909, so, should I update my paid Sandboxie 5.31.2 to the latest freeware version 5.33.1?

I have lost quite some trust with the whole Sophos fiasco... You, who are running the latest SBIE v5.33.1 on 64-bit Windows 10 v1909, do you find it working without any problems? And more importantly, do you still find it to be "bulletproof"?

Thank you.

 

adjust sandboxie according to your windows build. but remember that patches for 1909 also arrive for lower builds. you also can still use 1809 and get updates until "12. Mai 2020" (1803 is EOS since nov'2019) - but you wont have the latest features as in 1909
https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet
i would stick with 5.33.1

 

Update re #5998.
My reported CompPkgSrv issue has resolved.
My excuse is operator error.
My explain is RuntimeBroker.exe ... runtimebroker.exe somehow sneaked in with my Start/Run Access.
My daily rider Firefox sandbox always only has firefox.exe with Internet Access n' Start/Run Access.
On my setup when RuntimeBroker has Start/Run Access ... CompPkgSrv apparently wants to play, too.
When I started seeing 1308 CompPkgSrv messages. I head scratched over comppkgsrv.exe.

So, I Removed Start/Run Access for runtimebroker.exe.
Added HideMessage for runtimebroker.exe.
I had HideMessage=2222 =2314...but, did not have HideMessage=1308 for runtimebroker.exe.
And removed HideMessages for CompPkgSrv.exe.

At this time I'm not seeing 1308 CompPkgSrv prompts nor finding Clsid {n-n-n-n-n} ComponentPackageSupportServer with Resource Access Monitor.

Imagine those in-the-know...know the relationship between RunTimeBroker and CompPkgSrv.

Thanks to all that replied to #5998, etc.

 

Hi Bell. Sandboxie is working great in W10 1909 18363.535. Sandboxie is not perfect (it has never been) but for the most part, most activities done under Sandboxie are fine.

The only thing that's not working as it should that I can think of right now other than the conflict with MSI installers is that you cant open pdf files with readers like Foxit while using Firefox. You can download the pdf and view them outside the browser sandbox but they wont open while browsing. Other than that, all is well. Since I don't use other browsers, I am not sure if this issue also happens with Chrome, etc.

You should have update months ago.

Bo

 

Hi, well, it worked pretty perfectly for me so far, for the last 10 years... Some trouble here and there, the biggest lately with the MSI files, but no dealbreakers. I'm more scared of vulnerability, now, that there's no real communication between the SBIE team and us, there's no feedback, it's only us users now...

I didn't have a real reason to update so far (well I did, on my other machine), so I'm just fine with that, but I will soon, as Windows goes on with the updates...

Thanks.

 

Any news on sanboxie becoming open-source yet?

 

Probably is going to be around the middle of the year. Personally, I would much rather if it took a lot longer than that.

Bo

 

True, there is not much if any communication between users and the developer but the fact is that Curt is still developing Sandboxie. IMO, that's whats important.

Bo

 

Thanks