Hi Indan, I appreciate your attempt to change my opinion on how to design security solutions. Anyway, my opinion is based, not only on theory, but also in experience breaking stuff. This allowed me to build an idea of how hard is to break something, I mean, not only finding a vulnerability, but also weaponizing the exploitation. Here we enter into the field of 0days, chained exploits, hardening techniques, and so on. I did this for two decades, pionereed explotation, etc... if you ever wrote an exploit based on ROP/JOP techniques, well... I was doing that before those techiques ever got baptized (check Wikipedia) on some ot the hardest targets you can figure out.
For that reason, I trust my vision on security and my experience on exploitation. And this is useful, because it allows me to decide if a security solution is harder to exploit than other. As an attacker I prefer to face a protection based on "sandbox" built by OS mechanisms that facing a virtualization. By far, with my sun glasses and a mojito. You, as an experienced exploit writer I guess you are as per your words... you may prefer to fight a virtualization security solution. No problem. The only thing we both agree is seL4 on bare metal is the most secure solution. It's easy to agree on that. Beyond that, I believe it will be more than difficult we agree on anything related to hardening or exploitation. Fortunately for both this will not be a problem. seL4 is open so anyone can choose how to implement it. Good luck escaping hypervisors, is a fascinating topic, specially if the hypervisor is seL4, as you need to deal with very complex exploits (usually ring 0 chains). Best, El vie., 19 abr. 2024 18:13, Indan Zupancic <in...@nul.nu> escribió: > Hello Hugo, > > On 2024-04-19 13:59, Hugo V.C. wrote: > > I talked about "vendors" in general. Never specified about any > > particular vendor. It is a generalization. > > The context was browsers, there are not many browser vendors. > Furthermore, you used it as an argument to propose your idea. > If you didn't mean to include Mozilla you should have used > a different argument to use your complex scheme instead of > improving Firefox. > > > But containing damage to the OS this is a BIG step ahead. > > In example, to stop ransomware. > > It's not a big step ahead compared to a process contained with > the existing OS containment features there are, like running it > as a different user and using file permissions. In both cases > either a kernel exploit or infrastructure exploit is needed to > gain access to the rest of the system. Perhaps the attack surface > is a bit smaller, but that depends on the implementation. > > > "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. > > I would think the answer would be because it's pointless. > > > "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. > > You clearly don't take security really seriously if run security > critical software mixed with untrusted software on x86. That's what > I would call taking calculated risks. > > > 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. > > Running seL4 on bare metal is a lot simpler than porting existing > software to seL4. > > To me it sounds like you only use seL4 to run a Linux guest OS, > which only runs a browser. In this scenario the added value of > using seL4 is low. > > > seL4 is the future, it will penetrate every market, but we need > > to make people know it. > > seL4 is not magic pixie dust, it's a microkernel that does as little > as possible and doesn't yet have any extensive user space frameworks > that normal developers expect from an OS when developing software. > > The quality of an seL4 system depends on the design and implementation > of the system as a whole, it's easy to create an insecure seL4 system. > > > > > "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. > > Great, but that's virtualisation. What does seL4 add to that in how > you use it? What features of seL4 are you using to improve security? > > > > > "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". > > The point I am trying to make is that the reason you want seL4 and > virtualisation is because you don't trust Linux to handle all system > calls securely. You trust glue code if it's limited enough in size. > > Well, you can easily limit system calls in Linux. All the calls you > don't trust you can delegate to a small, trusted browser process which > does a limited set of system calls necessary for the browser to > function. > But all the expensive, complex code you can run contained with no > generic system call access, just access to a few selected calls that > are necessary to function and to communicate with the syscall task. > > > 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. > > You only need to change one browser and people that care about that > will use it instead of something else. Exactly the same as with your > proposed solution. > > > "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 am saying that OS "user" separation largely achieves what you achieve > with virtualisation from a functional point of view. I'm trying to get > an argument out of you why virtualisation + infrastructure to make it > usable is significantly better than just using the OS mechanisms that > are already provided. Both hardware and software have been proven to be > broken in the past. > > Using existing OS features to contain processes is already not done > in practice because it's too much hassle. Virtualisation only adds > more complexity. > > > > > I propose the same QubesOS is doing, thanks to seL4, but on top of > > standard OSs so people do not need to change OS. > > To me it sounds like you should just use QubesOS. > > Greetings, > > Indan > _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
