Hi Indan. "Both Chromium and Firefox are open-source. Calling Mozilla and all the volunteers unethical is unkind. Nothing is stopping you and like minded people from forking and creating a version which is more secure."
I talked about "vendors" in general. Never specified about any particular vendor. It is a generalization. If we can't generalize then switch off the debate... Water does not boil at 100 degrees... always... I love Mozilla work. They invented Rust. I love and appreciate volunteers work around the World. Sadly, this do not changes the fact that vendors (in general) are unethical. "This doesn't solve the problem of insecurity on the browser side, it at best helps to contain the damage if a browser process is compromised. But it only contains damage towards the OS side, not towards the user. Considering how much is done in browsers nowadays, an attacker is pretty much done if they have the same information and access as the browser has." Step by Step Indan... Yes, I know that. But containing damage to the OS this is a BIG step ahead. In example, to stop ransomware. Ransomware doesn't come hide in donuts... it comes in software users run in the OS, so very firsts step is stop such software to be able to reach the OS. Next step would be to limit what can to the browser. And next to separate usage. This is something browsers have tried ad nauseam unsuccessfully (they keep using OS API for this purpose and attackers just bypass those "sandboxes"). So Yes. First, we contain the damage. The problem you are talking about is for a "next phase". "Of course adding another layer of indirection makes live harder for attackers. Following this line of through, why stop with one nested virtual machine, why not keep going?" You know the answer: performance. "You could nest Linux on top of seL4 on top of Linux." I already do that Indan. On production. seL4 amazing performance makes nested virtualization penalty assumable to me and there are scenarios (critical services) where security comes first, at least in my business. "On the other hand, it makes everything more complex" I agree. I attach to the KISS principle. But there's not a solution that fits everywhere. Until I have a decent way of deploying seL4 bare metal solutions (which doesn't require me to recruit SpaceX engineers) I run seL4 virtualized. Then I move the virtualized environment to different OSs. This boosts my dev. It is a matter of being. On the other hand, unless you convince some billions of Windows users to switch to seL4 running on a C3P0 hardware without GPU support, they are left without a solution other than: "your OS is a s**t" we don't develop solution on top of s**t. I don't think this is the path to convince people to adopt new technologies. I prefer to give options. I prefer to give the option of running seL4 on top of Linux or Windows or Mac and then, give time to time... seL4 is the future, it will penetrate every market, but we need to make people know it. "and that will give more attack vectors in itself." I have had this discussion many times. Yes. Theoretically is what you say. In the real World (the one where an attacker evaluates the attack surface), whe you have ested virtualization, you are left to: 1) reachable tcp/ip stack (you don't reach ALL the tcp/ip stacks of the virtualized layers, just one, the rest is "glue" software) 2) permissions of the glue software of component of (1). Is it a qemu driver? Don't like qemu driver security? Nor me. Then let's focus on this, as THIS is a real entry point. Once you pass the packets to seL4, game is over for the attacker. You can't do dirty hyercalls tricks (like with other hypervisors) to escape. 3) the app/OS in the guest. I don't care, to me all this layer is just untrusted. I just care about separate untrusted environments in different virtualized roles Or in other words: yes, looks like there are more opportunities, but in reality the "added" opportunities are in a layer (emulation, hypervisors, etc) that represent a negligible amount of remote compromises, while all the compromises are on the layer of OS/app... virtualize it, and forget. "You can achieve the same level of security by disallowing most of the browser code from making system calls and not using any virtualisation at all." Here i don't understand. You can't do nothing without system calls... Everything is a system call. Maybe the tricky word is "most". This means maintaining a fork of a browser. Every browser. Not affordable. Nos scalable. Not real. It is easier to use QubesOS at this point... want to convince all the people to use QubesOS? Good luck. "But the same is true if a browser runs as a separate user, if it is compromised it is contained to what permissions it has, which can be very little. With your solution you just need to do it twice instead of once. Security wise, having to do the same thing twice isn't really more secure than having to do it once." No. This is the same to what QubesOS currently does. You can have a Work, Fun, Finnace... environemnts (Browsers). Which is very different than "users", are virtulized by Xen, please don't compare OS "user" separation to hypervisor separation... nothing to do. I propose the same QubesOS is doing, thanks to seL4, but on top of standard OSs so people do not need to change OS. El vie, 19 abr 2024 a las 12:03, Indan Zupancic (<in...@nul.nu>) escribió: > Hello Hugo, > > On 2024-04-19 10:06, Hugo V.C. wrote: > > 1) Let's forget the naive idea of users changing behavior or vendors > > making > > secure software. Users are "ignorant" and vendors are unethical. That's > > raw > > reality. > > Both Chromium and Firefox are open-source. Calling Mozilla and all the > volunteers unethical is unkind. Nothing is stopping you and like minded > people from forking and creating a version which is more secure. > > > 2) Let's forget about users using (wonderful) secure platforms (like > > QubesOS) or... ups..., looks there's nothing else, as seL4 is aimed for > > embedded world (right now) > > This doesn't solve the problem of insecurity on the browser side, it at > best helps to contain the damage if a browser process is compromised. > > But it only contains damage towards the OS side, not towards the user. > Considering how much is done in browsers nowadays, an attacker is pretty > much done if they have the same information and access as the browser > has. > > > The magic of seL4 is correctness. Anyway, this does not magically > > solves > > the Universe problems. But keeps being correct. > > > > There's no engineering limitation that avoids running seL4 on top of > > any > > other OS using virtualization functionality. And besides unfounded non > > engineering based facts, the reality is that an attacker will almost > > ALWAYS > > (exceptions are exceptions by definition) prefer a scenarios where seL4 > > is > > not present to the same scenario where seL4 is there. If anyone can > > prove > > I'm wrong here, please correct me. > > Of course adding another layer of indirection makes live harder for > attackers. Following this line of through, why stop with one nested > virtual machine, why not keep going? You could nest Linux on top > of seL4 on top of Linux. > > On the other hand, it makes everything more complex and that will > give more attack vectors in itself. > > Using an seL4 guest OS instead of a Linux guest OS can only stop attacks > that rely on weaknesses in the host OS that can be exploited by guest > kernels, but not from (guest) user space. > > You can achieve the same level of security by disallowing most of the > browser code from making system calls and not using any virtualisation > at all. > > > > > So, my proposal, is, of course, let's fight to try putting seL4 as > > close > > as possible to the silicon and anywhere if possible, but... if not > > possible, let's fight so put it somewhere else! > > > > In example: we have a scenario with Host OS (with nested virtualization > > enabled) ==> hypervisor XYZ ==> XYZ OS layer ==> Clown Buggy Browser > > > > we can convert this to: > > > > Host OS (with nested virtualization enabled) ==> seL4 ==> XYZ OS layer > > ==> > > Clown Buggy Browser > > > > As simple as this. In the last scenario is, by far, more complex (need > > to > > exploit drivers, tcp/ip stack, "glue" software) to jump from "Clown > > Buggy > > Browser" to "Host OS". And that's enough for me. > > But the same is true if a browser runs as a separate user, if it is > compromised > it is contained to what permissions it has, which can be very little. > With your > solution you just need to do it twice instead of once. Security wise, > having to > do the same thing twice isn't really more secure than having to do it > once. > > Greetings, > > Indan > > _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
