Improvements also affected the kernel as you can read here http://www.microsoft.com/security/sir/strategy/default.aspx#!section_3_3 https://technet.microsoft.com/en-us/windows/jj983723.aspx
Not bug-free - nothing guarantees that - but much lower likelihood of bugs, particularly exploitable ones. Also: mandatory access control is complicated. What happens when there's a vulnerability in the hypervisor? It's happened before with Xen.
Yes, stuff like SMEP and AppContainer are meant to mitigate exploits, but kernel exploits can bypass them, that's the whole point. Not a lot of hackers are going to try to hack the hypervisor. BTW, Safeguy said that Chrome was hardened against kernel exploits, perhaps I misunderstood, but do you perhaps know more about this?
That's what they said about kernel exploits a few years ago. Also whitelisting, HIPS, behavior blockers, Firefox, etc. etc. going further back. If it goes mainstream, people will try to hack it. Edit: re Chrome - on Windows, I believe it disables renderer access to a bunch of Win32 system calls. And yes, that sounds ridiculous, but it's possible because almost everything on Windows is a system call. From what I understand, it's not that different from the empty chroot jail on Linux, although... kludgier, because I don't think Windows provides a built in mechanism for it.
The point is, the harder it's to hack something the less chance that we will be getting to see attacks on a large scale. But what does this mean? Can hackers not use this attack surface anymore?
The question is whether it would actually be harder to hack, as opposed to just requiring different tactics. Hypervisors are typically hard to attack because they're small. But to implement MAC via a hypervisor, you'd have to have it hooking into the guest OS somehow, and it would have to have facilities in ring 0 (with the guest kernel in ring 1) to keep an eye on things. Which means more potential for compromise. If it's written in bug-prone C like everything else, and manages to go mainstream, good luck. Another reason I'm not keen on this is that, AFAIK, the only way to implement it on Windows would be to patch the kernel via the hypervisor, so that the hypervisor could hook in - i.e. to adulterate the guest kernel. That seems like risky business to me. (Note though, Bromium claims to do hypervisor-based sandboxing successfully, and I have no idea how they do it. OTOH - as I've probably opined before - I am skeptical of their claims, due to the shear amount of hype and secrecy involved. Such marketing tactics are IMO ethically dubious, and make me disinclined to take Bromium at face value.) Not sure if they can't, but it's certainly going to be harder.
Yes correct, this is the way it would work. I think the benefits outweigh the risk though. The only way to ensure the integrity of the kernel is by running on top of it. It would basically be PatchGuard "on steroids". BTW, I believe that Invincea also makes use of a hypervisor, so that would make Invincea Endpoint a bit more robust and harder to hack, I believe. It doesn't work the same as Bromium though, you can read more about it over here: http://www.invincea.com/2014/05/tech-throwdown-micro-virtualization/ http://www.techrepublic.com/blog/it...he-power-of-virtualization-to-combat-malware/
Than what would be Chrome's advantages (without Sandboxie) over using Sandboxie on top of Chrome? We talked about advantages for what is SBIE good for when you run it (Sandboxie) on top of Chrome, but what exactly are advantages of Chrome using and running without Sandboxie?
You can enjoy using your computer again. Invincea wouldn't need to spend 99% of its human resources dealing with and fixing Sandboxie / Chrome compatibility issues. Invincea might then be able to focus on applications where Sandboxie might actually make sense, like Office 365 (for heaven's sake, people!).
What kind of weird question is this? SBIE is a security tool designed to protect browsers like Chrome. But like FleischmannTV said, sometimes there may be compatibility issues, so that would be reason enough to run it without SBIE on top. But the last time I checked, Chrome ran quite smoothly combined with SBIE. Of course, you could also choose another security tool to protect Chrome, like AV, anti-exe and anti-exploit for example.
@FleischmannTV & @Rasheed187 -- As always gents, thanks for your witticism and your erudite replies for inquiring minds that want to know. BTW, Fleisch.., if you would care to share and run into this post specifically; curious to know what your go to replacement was in lieu of the intrepid Sandboxie.
To clarify, after all of this discussion it was IMO a bit of a weird answer to ask, especially because I know that CoolWebSearch has a lot of knowledge about this subject. But seems like he keeps confusing himself.
I use google chrome on linux. From what i understand this is a stronger sandbox than windows. Would this be correct.?
Thanks for this. ^^^ Is this true for Chromium, as well? I'm new to Chromium. Edit to rephrase -- This is what I get in about: SUID Sandbox Yes Namespace Sandbox No PID namespaces Yes Network namespaces Yes Seccomp-BPF sandbox Yes Seccomp-BPF sandbox supports TSYNC No Yama LSM enforcing No My Chromium version reports this as adequate sandboxing. From what I understand the sandbox differs depending upon the Linux distribution.
SUID Sandbox No Namespace Sandbox Yes PID name spaces Yes Network namespaces Yes Seccomp-BPF sandbox Yes Seccomp-BPF sandbox supports TSYNC Yes Yama LSM enforcing Yes You are adequately sandboxed. This is what chrome reports on linux mint 17.2.
My 'about' status in Mint Mate 17.2, Chromium, is the same as this ^^^^ . Post #492 report was from Debian Mate 8.1, Chromium.
Just a note - things have continued to improve. The SUID sandbox is removed, and the broker itself is sandboxed. I'm not overly familiar with the details anymore, but from what I can tell things have moved in a great direction. Privilege escalation on Linux, given a reasonably hardened setup, should be very costly - far less costly than other methods of attack.
No, it's still "Enabled by default (old kernels) and maintained" as not all distros support user namespaces. That's why chrome://sandbox gives different results. Interesting! Can you provide a source?
So, pure Seccomp now? Nice. It seems like Seccomp is becoming the de facto Linux standard for sandboxing, which... well, I heartily approve of that. Standardization of Linux userland stuff is a good thing IMO. I wonder if they plan to support Capsicum too, though. Capsicum on Linux is a Google project, and it was originally designed on FreeBSD, so that might be better for cross platform stuff... https://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811-usenix-capsicum.pdf A fine grained, capability based sandboxing implementation, portable between different UNIX systems, would be *awesome*.
