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 (
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