I wouldn't say it's becoming standard, I still don't know what other processes are using it. @summerheat Yeah, I suppose 'removed' is not the proper word. I hope it is not removed for a long time Not actually sure about the broker, but I had thought it was using seccomp, I may try to dig up some info on that.
I was actually suprised that you consider a removal as an improvement. From my understanding, seccomp-bpf filters system calls and, thus, protects the kernel but it doesn't block file system access etc. This is where the SUID sandbox comes in. As Chrome developer Julien Tinnes once wrote: Another thing is that the user namespace sandbox is aimed to replace the SUID sandbox, but as mentioned not all distros support that. The Arch Linux developers even see security problems. Hence, user namespces are not supported yet in Arch.
Seccomp is capable of restricting capabilities by virtue of its system call control. The issue is largely ergonomic, and I'm not entirely sure how things have changed, but if they've removed SUID the step forward is that SUID provides some messy attack surface whereas seccomp is very clean and requires no special permissions. Yes, seems more likely that it's removed instead and user namespacing is replaced. I mentioned those same security concerns in another topic here, I am not a fan of userspace namespacing.
In my Setup a) Set UAC to deny elevation of any unsigned process b) Add a deny execute ACL for everyone to all folders Chrome has write access to c) Use Chrome's build in sandbox based on Intergrity levels, User objects and alternate desktop d) Other Chrome security related features, check the list of command switches - enable win32K lockdown mode (is now default only disable switch exists) - strict mode (use restricted set of javascript of ECMAScript 5) - Virtual Javascript Machine with its hidden classes (definitely harder to exploit than libraries) I am using Chromium latest in stead of Chrome (chromium is unsigned, so the broker process and dll's can't elevate and attack high-il objects) So even on Windows Chrome sandbox can be tightened by using build-in OS features (UAC/ACL)
Setup for people wanting to use Chrome instead of chromium with additional tightening on Windows (is set and forget) 1. Add an extra process whitelist layer around Chrome broker (because of User objects, renderer processes are only allowed to spawn one executable already) Install Smart Object Blocker in behavioral mode and select these rules (available in default set) a) allow chrome only to launch chrome and google updater. b) allow chrome only to launch microsoft signed DLL's located in C:\Windows\* and Google signed processes from C:\Program Files\Google\Chrome\* 2. Add an extra deny execute layer on Chrome folders (Chrome also protects its user folders, so add Everyone don't change existing access rights_ a) Set a deny execute for everyone on downloads folder b) Set a deny execute for everyone on TEMP-LOW c) Set a deny execute for everyone on AppData\Local\Google\Chrome\User Data d) Remove this new ACL from C:\Users\Kees\AppData\Local\Google\Chrome\User Data\PepperFlash e) Remove write rights for yourself in folder C:\Users\Kees\AppData\Local\Google\Chrome\User Data\PepperFlash (Google update elevates, always throws an UAC popup, thus it can change this folder using its elevated right), This is due to bad habit of chrome installing flash patches in user folders (in stead in Program Files). Add Malware Bytes Anti-exploit FREE to the mix (also allow its DLL to load in SOB) and a simple Adblocker (I like Adguard best because it will always work, uBlock due to its extra settings and adviced defaults sometimes breaks sites)
Just wondering.... If you do all that you mentioned here in the last 2 posts, just wondering is Google Chrome with all of these tightenings tougher than running Google Chrome with all these additional tightenings inside Sandboxie (with start-run restrictions)-I'm not sure if Sandboxie is even useful anymore, unless you want to block even more with Start/Run restrictions-I wonder if anyone has ever tried this and of course if with Chrome and than running this tightly restricted Chrome (as you described above in the last 2 posts, Windows Security) inside tightly configured/tightly restricted Sandboxie would it be tougher to beat/exploit than tightly configured/tightly restricted Chrome without Sandboxie? Would than this all be too much over-redundant to run this soooo much tightly configured/tightly restricted Google Chrome inside tightly configured/tightly restricted Sandboxie? Just wondering.... And I wonder if can you do the same restrictions/tightenings with Microsoft Edge in Windows 10?
ACL is available in every windows version. It just leverages the fact that Chrome (and chromium) only allow access to a few specific folders. So setting a deny execute ACL in those folders is seamless (because in normal situations you would never execute something in it). I use Edge as PDF-reader (not allowing flash to run nor javascript to execute nor internet access), but I think the difference between IE and Edge is that Edge does not allow you choose a different download folder. So you could set a ACL deny execute in the Download folder. I would have to use Process Monitor of sysinternals to check which folders are used by Edge to lock them also with ACL. I have played with Smart Object Blocker and you can tighten Edge in the same way as Chrome with Smart Object Blocker. So you could build a container around Edge with ACL and SOB. I just explained the alternative 2 for people looking for a free sandbox (i think container is more appropriate) solution around their browser. Since Chrome is not exploited in the wild for (a think five years now), every claim of Chrome being safer with or without program X is arbitrary IMO, so really can't answer your question about situation A being safer as B in regard to Chrome.
I will try to reformulate the question: since it was purely my hunch that if you do that what you have written second post, I was just wondering if it is the same as run Chrome inside Sandboxie (with tight restriction configuration settings-so start/run restrictions-based on what I've seen is that if you do that what you written in your second post about restriction configuration is the same as running Chrome inside tightly restricted/configured Sandboxie. OK, sorry for my bad english-in short-if you do with Chrome what you have written in second post I presume, it will be exactly the same as running Chrome inside tightly restricted/configured Sandboxie-because of the restrictions put in ACL-basically if you do with Chrome what you have written in your second post or the first post, it will simulate the protection of Google Chrome running inside of tightly configured/restricted Sandboxie? This is how I understood it-I hope you understood what I meant to ask..... Now Edge seems to be another Chrome when it comes to security and protection.
@CoolWebSearch The combo SmartObjectBlocker and ACL would have simular effect as running Chrome in a tightly configured sandbox with following differences SOB+ACL vs SBIE a) ACL only blocks execution access while SBIE redirects also data access (virtualises) b) SBIE (to my knowledge) only blocks executables in start/stop, while SOB also blocks (and whitelists) DLL's Some argue SBIE's virtualisation puts a hole in Chrome's policy sandbox (redirect in stead of hard block) while other argue SBIE adds an additional layer so this makes it harder to exploit due to increased complexity. Honestly is all theory. Looking at the real world there is only one example of the first and there are more post mentioning SBIE would have protected against an exploit, so I lean towards the second opinion. Regards Kees
Big thanks, Kees. Just for the record; Sandboxie does block DLLs, but you have to configure it manually, of course some of the dlls are unblockable since they are part of Windows core system-am I right about this? Yes, I do know that Sandboxie does block DLLs with enough configuration, just not all of them-the one it does not block are Windows core dlls-that are crucial for Windows to run in the first place, if you block these dlls, the Windows would not work-am I right? This would mean that SOB also cannot block dlls that are vital and crucial for Windows to run in the first place-right? You said there is only one example of the first theory where SBIE's virtualization puts a hole in Chrome's policy sandbox -do you know maybe when it was? Was this discussed here on Sandboxie forums-do you perhaps have a link of website or a forum for this info? what about posts that support the other theory-that SBIE-would have protected against an exploit-do you perhaps have a link of website or a forum for this info? Big thanks again, Kees.
Kees, you don't mind, if I copy all of these helpful guides in my Microsoft Word, do you? It would be crucial for me next week when I finally install Windows 10.
@CoolWebSearch With SOB you can whitelist DLL's from Windows signed by microsoft and whitelist DLL's from Chrome\Application signed by Chrome for Chrome, it are just two rules to add. When you want to run MBAE, just whitelist its DLL and your are done, You can also set Chrome to launch chrome.exe only. This way you know nobody has messed with your Browser (man in the browser prevention). When you download something, it is downloaded in a directory (Downloads) with a deny execute ACL. Therefore it is more a policy sandbox and not an application virtualization sandbox like SBIE. I know of one case, it is mentioned in Sandboxie forum also. After it reported it was closed withing with a few hours by Curt. Regarding the information posted. It is information freely available, so I can not (and will not) claim authorship. You are free to use it in any document As far as I know all those chrome switches are on by default now (there are some interesting new beta switches)
WoW ! after 21 pages of reading (which 3/4 are ping-pong argues quotes and linux offtopics ) i'm still not sure if running Sbie on top of Chrome is a security risk to Chrome's (and its own sandbox) and my system; not saying i'm quite a computer literate, i don't even imagine people who are not... : Fact i knew: - Sandboxie contains whatever is run inside it. facts i understood: 1- Chrome's sandbox is strong enough and suffice for himself. 2- Sbie use the same windows mechanism as Chrome and add its driver thingy (forgot the exact name) 3- Both can be bypassed by kernel exploits. 4- both can be bypassed with targeted exploits. (hence using an HIPS or Anti-exec should prevent this) 5- Runing a sandbox in a sandbox is same as running 2 AVs together (unless they works in different way). all this to come to : so still in the doubt... (correct me if i'm wrong somewhere.)
You will not encounter an attack that needs Chrome to run inside Sandboxie in order to work. It's possible, but probably as unlikely as winning the lottery while being struck by lightning twice. Though, if I were worried, I would be much more worried about Comodo as a security risk, making escapes from either Chrome or Sandboxie easier. It is actually stronger and so it should suffice. The multi-process architecture allows for restrictions that just cannot be achieved with Sandboxie without breaking the program running inside it. Though it has to be said that Sandboxie can protect from stupidity, which the Chromium sandbox cannot. More like running two instances of the same AV. I understand, but don't expect real answers to your questions here. The people who actually understand these things - and I don't count myself among them - do not participate in forums like this, because they have no reason to. They will gain nothing from it but personal attacks. So in the end it's more like a religious debate between security product fanboys.
It's complete bullocks about SBIE being a risk to Chrome, unless you're worried about targeted attacks that will only work when SBIE and Chrome are combined. SBIE protects Chrome just like it protects any other browser, it comes down to this: Chrome browser exploit: Chrome without Sandboxie on top ----> Game over Chrome with Sandboxie on top ----> Malware contained Chrome browser + kernel exploit: Chrome without Sandboxie on top ----> Game over Chrome with Sandboxie on top ----> Malware might be contained. If SBIE is targeted ----> Game over
@Rasheed187 if SBIE is exploited, it could break Chrome's sandbox. All those situations are only theoretical of course.
A question from guest (see bold part): " WoW ! after 21 pages of reading (which 3/4 are ping-pong argues quotes and linux offtopics ) i'm still not sure if running Sbie on top of Chrome is a security risk to Chrome's (and its own sandbox) and my system; not saying i'm quite a computer literate, i don't even imagine people who are not... :"
@ Minimalist If you think about it in that way, then SBIE is a risk to all browsers. Because if it gets exploited, it can't protect FF and IE either. But I hear you say, "wait a minute, if you used Chrome, then you would still be safe!" Yes correct, but that's only because it was SBIE that was attacked, and not Chrome. If you attack Chrome, it's vice versa again. And yes, normally speaking it's not security tools that are under attack, but the end user application, like the browser or media player.
I think it should be re-iterated that google chrome does not in fact have a sandbox but relies on mandatory access controls hosted by the native operating system. In this respect linux offers a far more stronger set of options for chrome than windows. This did need to be pointed out as the term sandbox should only be applied to sandboxie and equivalent programs. Priviledge restrictions would be more applicable to chrome. Software containment for sandboxie. Different strategies.
Somebody needs to inform Google Chrome that their browser does not have a sandbox. Excerpted from here.
misuse of the english language. Sandboxie. Chrome SANDBOX. if chrome has its own "native" sandbox could you please explain why the chrome sandbox on linux is considered stronger than on windows.? Let me enlighten you. chrome uses what the chosen operating system offers..! Does not sound very "native" to me. Chrome is in fact relying on the access controls already extant on the chosen operating system. It is not chrome which is protecting us but rather the restrictions ALREADY in place on the operating system.
finally some informative posts i don't care of "surface attacks" , it is the same as saying "don't use a condom , if you do , maybe some lubricant may reduce its protection" Anyway if someone worries about surface attacks , better stop using a computer and go to the library and read books For what i thought and it seems i was right after reading those posts above , Chrome isn't a "real sandbox ", it is just policy-restriction based ( as webroot's "sandbox" or comodo "auto-sandbox") opposed to Sandboxie's full isolation (from its driver and other associated mechanisms, etc...).
I understand it in this way: Chrome uses restrictions sandbox, Sandboxie uses virtualization (and you can add restrictions if you want and can). So anyway there's some gain in SBIE + Chrome combo. Here term "sandbox" is used in two different ways as "restriction" (it refers to Chrome) and "virtualization" (to SBIE). So there's some confusion possible. As for Comodo their restriction auto-sandbox was long ago in earlier versions. Now you can make it virtualization or restriction or both together.
