They said "sandboxie can't handle the Lowbox Token" , without much infos. The quote is lost somewhere on this thread I guess implementing it will need a full rewrite of Sandboxie.
Why not rewrite Sandboxie, eventually-after all security and protection are the most important combined with usability without bugs and all other errors.
Sandboxie uses untrusted integrity level and guest user rights combined with its own user and kernel filtering mechanisme. The guest user feature allows the process to be sandboxed to read all data. The untrusted integrity level, makes sure the sandboxed process is unable to change objects of medium and high level integrity. Because the filtering mechanism redirects data to the sandbox folder, the filter mechanism of Sandboxie can selectively grant access to (probably low right ACL) folder in the sandbox (the virtualized data which the sandboxed program is changing). The filter mechanism Sandboxie probably also monitors inter program messaging and access to general windows user and kernel functions. For processes to work in the much more restricted AppContainer, the process being sandboxed has to be designed to function properly in the AppContainer sandbox. The way Sandboxie seamlessly sandboxes programs not designed to function properly in a Sandbox using u trusted Integrity level and Guest is just possible with Low box token and Appcontainer. So there is no such thing as a rewrite of Sandboxie to be able to use AppContainer sandbox. To be able to use AppContainer a rewrite of the program you want to sandbox is necessary. Apologize for the many probablies, because I have not reverse engineered Sbie (I am just making educated guesses).
After using Comodo sandbox on chrome and firefox, it seems it doesn't affect the browser's integrity If you really want to, you could try Comodo firewall(they still haven't release a standalone sandbox product). But honestly, you should be fine with Sandboxie. I haven't tweak much of the settings in either Sandboxie or Comodo sandbox, so I can't say which one is better or more tight. Either @guest or @cruelsister Should be able to answer your question.
Personally , too many tweaks to do , i spent days of research, trial & errors... discussion here : https://malwaretips.com/threads/comodo-internet-security-v8-setup-configuration-thread.53121/ to result as this : https://malwaretips.com/threads/com...etup-configuration-thread-setting-only.53271/ You are right , i surrendered with Comodo , have spent hours to set a "perfect tight" setup then all vanish because all rules are deleted from a obscure bug...must redo all tweaks (unless you exported them)
The thing that people seem to forget is that a Chrome exploit doesn't automatically bypasses Sandboxie. So SBIE can still protect Chrome even though it's a third party sandbox on top. So all the discussion about AppContainer doesn't even matter. At the end of the day it's Chrome that's being attacked and not SBIE.
So you're telling me AppContainer "doesn't even matter" as if the Chrome exploit is definitely not affected by it? I'm afraid you're the only one harping about SBIE inadvertently containing a Chrome exploit...
J_L, I apologize for this, but I'm a bit lost what on you meant here, I have a hunch, but I'm still not sure what exactly did you mean by this post, could you, perhaps be more precise-sorry, I still have problems with English language since it is not my first language. What did you exactly mean Appcontainer does not even matter, as if the Chrome exploit is definitely not affected by it-did you mean in a sense that Rasheed's post suggests that Appcontainer cannot protect Chrome against exploits? And what do you mean by "you're the only one harping about SBIE inadvertently containing a Chrome exploit"-did you mean that Rasheed thinks that Appcontainer cannot fully protect against exploits both Chrome and SBIE and SBIE is like the only one which can actually fully protect Chrome from Chrome's exploits and from Sandboxie exploits as well, or you meant something else? Big thanks in advance.
@CoolWebSearch : If I may give you a friendly advice, then this thread is not something you should use a lot of energy on. Especially since you keep stating that you have difficulties understanding what posters actually meant. This thread are just a far to long running philosophical debate about if a sandbox are safer when wrapped inside another sandbox, or if a sandbox malfunctions when wrapped inside another sandbox. One side argues that wrapping sandboxes inside each other are the best way to do things, because they are sure that the second sandbox are the holy grail. The other side argues that wrapping sandboxes will be pointless or perhaps even lower security, due to the inner sandbox being unable to freely interact with system as it was designed to. Nobody in this thread has tested anything. It's just a philosophical debate on thoughts, feelings and ideas. A new aspect has lately been introduced when posters realized that the native OS sandbox AppContainer was actually a lot more restricted and locked down than those sandboxes they have been philosophic about for ages in this thread. AppContainter runs at the lowest possible integrity level, with kernel and system access locked down. All settings are done by the developers behind each use of it when they write the manifest for the app they are building. You as a user have no saying in its use. You just lean back and enjoy being protected. Edge and all UWP apps runs in AppContainer. No need to worry about compatibility, usability or stability when using apps, updating them or updating Windows. AppContainer are locked down by design. Chrome, also intended to be safe out of the box. There are however access to a number of flags you can set to lock it down even further. Those are not enabled by default yet, since some are still being fine tuned and tested before ready to mass deployment. You can enable those flags you feel like testing or wait for Chrome developers to deem a feature ready for primetime and thereby enabled by default. Sandboxie - flexible, but at a cost. You can throw almost anything in it, but it often breaks when bigger updates are rolled out for Windows and you have no guarantee that your sandboxed programs still work when new versions of your preferred programs are released. It's a bit of a mouse and cat game, where you need to be on constant alert. It can be very powerful for a enthusiast who love to tinker with settings, but not something that can ever be mass deployed. All in all, you can say a lot of good things about all three subjects mentioned above - but zero good things about this thread. There's nothing to gain for you by trying to make heads and tails in a debate between philosophic statements that none has ever tested or verified.
I'm not sure what you mean, are you saying that you don't believe SBIE can contain malware that's launched via a Chrome exploit? And perhaps I misunderstood the latest discussion, but I got the feeling that people were once again comparing the Chrome sandbox with SBIE, while that doesn't make a lot of sense IMO. Like I said, if Chrome is exploited, it's game over just like with any other browser, with or without sandbox. So you still need anti-exploit, AV or third party sandbox.
That's true, but it's also a bit about logical thinking. I really don't see how a Chrome exploit that takes advantage of specific vulnerabilities in Chrome, can somehow automatically bypass SBIE. If that was the case, then yes it would be pointless to run SBIE on top. And the "lower security" argument also doesn't make a lot of sense. In theory it's possible to write an exploit that only works when Chrome and SBIE are combined, but why the heck would you want to do that?
Hi Martin, I like your post, I think its a very nice post. But I don't agree with the way you are using the word "often" to describe how programs interact with Sandboxie after getting updated. I run a lot of programs sandboxed and hardly ever anything that I run in a sandbox breaks after any of this programs or Sandboxie updates. Its actually very rare for something to break after an update. Let me give you a couple of examples. I have been using Sandboxie for more than 7 years. My browser is Firefox. Only once in this seven years installing a Windows update broke using Firefox under Sandboxie. Thats only once in 7 years. In my personal case, since I disable Windows updates and install the updates at my own pace, Firefox did not break. Thats because the Sandboxies team is always on top maintaining Sandboxie. That month when this happened in 2010, the new Sandboxie version that took care of the problem was released 24/36 hours after Microsoft released Windows updates that month. So, by the time I installed the important updates of that month, I already had the new SBIE verdsion that took care of the issue. Many Sandboxie issues have to do with conflicts with other security programs. I don't use any real time scanners to protect my computers but if I was using an AV, I would be using MSE in W7 or if I was using W10, I would have Windows defender. I mention WD for two reason, one, I know you like it, I also like it and two, the only time that MSE Wd has not worked with SBIE was when MSE was first released. Thats a long time without WD breaking with SBIE. Not once in the past 7 plus years has there been any problem using WD or MSE along SBIE. Using my PDF reader, WinRar, HJ Split, video players that I use, Office in XP and Libre in W7, you name the program that I use, using it under Sandboxie never breaks. For people using W10, things might not be as nice as I described but that's because is a new system that has not settled down yet. Bo
Yes to first question. As for second question, it mainly has to do with the fact that Rasheed likes to mention the same Chrome exploit SBIE happened to contain. We've already gone over that. Great points and all, but this isn't just philosophy. At least I (and quite a few others) have had real-world scenarios discussed to death, which may be why it looks philosophical now. For example, do you really need to test or verify what is clearly common sense: users don't normally get infected via drive-by exploits from the browser? That is my main point here, while others still use SBIE for reasons I've pretty much all listed (with some help): https://www.wilderssecurity.com/threads/chrome-sandboxed.377440/page-15#post-2511965 And I mentioned AppContainer way back, but you're right: only now are people seeing its true potential. But there were other subjects mentioned as well, from anti-exploit to virtual machines. And I just don't like how you downplay this thread's involvement in people learning more about the conundrum of sandboxing a sandbox. Lastly, this is not as black-and-white as you make it appear. There may be 2 sides, but the arguments are far from SBIE being either a compliment or detriment to Chrome, especially at this point of the conversation. No I'm just tired of you bringing up that same point over and over again, especially when it's not really relevant to the discussion. Do note that they only test Chrome with its default settings (at least not without hardening via AppContainer & whatnot AFAIK), you're exaggerating on the likelihood of being exploited by a drive-by install, and 3rd party tools are far from proven to be "needed".
Like I said, I might have misunderstood the latest discussion about AppContainer. So you're basically saying that AppContainer will make Chrome and Edge harder to hack? That might be true, but my comment was directed to certain posts that compared Chrome with SBIE. My point was: Just because SBIE doesn't make use of AppContainer, doesn't mean it's less secure. And BTW, the reason why you don't get to see Chrome attacks ITW is because Google and other companies pay big bugs for these type of holes. So thinking that you probably don't need a third party security tool is silly if you ask me, because you never know if such a hole will be used in a large scale attack, better be safe than sorry. http://www.forbes.com/sites/andygre...pc-and-get-paid-six-figure-fees/#6024b2e94483 https://threatpost.com/vupen-launches-new-zero-day-acquisition-firm-zerodium/113933/
OK but fact of the matter is; they tend to only test programs using their default configuration, and 3rd party security tools are far from proven to be more reliable than hardening the settings in those kind of scenarios.
Well, at the end of the day anything can be hacked. But yes, I also get the impression that it's quite hard to hack browsers like Edge and Chrome, otherwise we would surely see more wide scale attacks like with IE back in the days. But still, I would never blindly rely on a browser's sandbox, you never know when a zero day might pop up. I do agree that protecting Chrome with anti-exploit or anti-exe makes more sense than running a third party sandbox on top. Speaking of exploits, we should not forget that you don't even need a browser exploit to bypass the browser sandbox, you can also try to get remote code execution and then elevate privileges with a kernel exploit. So if you use a browser + kernel exploit you can even bypass third party security tools as a bonus.
And like J_L said you can tweak those web-browsers even more, so they can be protected equally against exploits and against everything else as much as like they are running inside properly and tightly configured Sandboxie-so your point here is a moot point. That's why I said, tightly and properly configured lock down Chrome (NOT Chrome on default settings, but tightly and properly Chrome in lock down mode) can block and it does block half of the Windows kernel with win32k lock down, plus with AppContainer is actually harder and tighter than tightly and properly configured Sandboxie on top of tightly and properly configured Chrome-but personally, I do not care, I simply like Sandboxie, and that's why I use it. For exploits, if you want true protection, take and use HitmanPro.Alert.
May be it is because I am Dutch, but I dislike elitarian advise to stay out of a thread, because it is over someone's head. Good on you, good conclusion. Let's close this thread
Maybe it's because I'm not Dutch and the two of us are therefore located in different countries, that we read different meanings into the posted words. Nowhere did I give elitarian advice or tell anyone to stay out. I posted a advice to @CoolWebSearch due to the fact that he/she keeps stating to be struggling with a language barrier. When you combine that with the fact that this thread has zero real world relevance, then I really don't think it's something one should waste time on trying to understand. If this thread had a juicy POC or a fresh in-the-wild sample being tested on every second page of this marathon thread - THEN this tread would be meaningful. Instead this thread are nothing more then the same statements over and over again. Somebody THINKS that MAYBE, or WHAT IF, or PERHAPS it COULD BE. It's philosophic. There's the Bromium, and well, Bromium are Bromium. There's a group of users at Wilders who enjoy these debates on ideas, thoughts and feelings. None of them has any ill intentions. They just enjoy a good healthy discussion. Nothing wrong with that. Great ideas often comes from great discussions. The problems begins when not-so-frequent-Wilders starts to believe that these ideas, thoughts or what-if's are facts that they need to implement in their own setup.
I don't know if this sarcasm, but I think thread is probably getting on your nerves; I'm not surprised, I'm the one who is responsible for this, what can I say, that's my weakness, kill me for being imperfect.
Hard words, but they are true, and truth hurts. But why would this thread be closed just because scenarios are hypothetical and philosophical?
I'll have to mostly agree with @Martin_C on this. Although I don't see the thread being as pointless as he does, @CoolWebSearch and people like him are not going to benefit from any further hypothetical discussions. To be honest, I think it may even be detrimental to the mental health of say CWS trying to understand all of this without even fully knowing the meaning of our conversation. In the case of CWS, I find that he is being influenced all over the place and cannot seem to have his own resolution. We're even running out of hypothetical things to say, and starting to repeat what we've forgotten. Heck I'm starting to suspect that some have chosen to ignore/forget specific details and thus are posting the same things again as if they haven't been settled. Then we have new people joining the thread, which makes it that much more complicated. I don't know how all of this can be resolved outside of burying the dead horse, so maybe it is time to close this thread. But I do hope CWS and others like him will find their resolution and stick to it, instead of worrying about hypothetical situation all the time.
MemProtect ended this discussion. Memprotect is a tiny (25K) driver that enables windows internal process protection. Originally developed to protect system processes and available to security software as well. With AppContainer feature and ACL deny execute on download folder, it is the best (OS-enforced) sandox possible. See link So no don't sandbox with Sandboxie, sandbox with MemProtect, AppContainer and ACL (use OS features). Best thing about MemProtect: it is free!
Actually, the discussion was ended a longtime ago. But let's continue in the Bouncer thread, because I don't understand what MemProtect is all about. And let's not start a new "SBIE vs anti-exploit vs Chrome sandbox" discussion.
