Rust to be allowed for Chromium development
Our goal in bringing Rust into Chromium is to provide a simpler (no IPC) and safer (less complex C++ overall, no memory safety bugs in a sandbox either) way to satisfy the rule of two, in order to speed up development (less code to write, less design docs, less security review) and improve the security (increasing the number of lines of code without memory safety bugs, decreasing the bug density of code) of Chrome. And we believe that we can use third-party Rust libraries to work toward this goal.Rust was developed by Mozilla specifically for use in writing a browser, so it’s very fitting that Chromium would finally begin to rely on this technology too. Thank you Mozilla for your huge contribution to the systems software industry. Rust has been an incredible proof that we should be able to expect a language to provide safety while also being performant.
Posted Jan 12, 2023 21:08 UTC (Thu)
by bartoc (guest, #124262)
[Link] (10 responses)
Posted Jan 12, 2023 21:21 UTC (Thu)
by claude.bing (subscriber, #127877)
[Link] (9 responses)
The Rule Of 2 is: Pick no more than 2 of
* untrustworthy inputs;
Posted Jan 12, 2023 21:35 UTC (Thu)
by bartoc (guest, #124262)
[Link] (8 responses)
Posted Jan 13, 2023 8:21 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (7 responses)
You'll see me railing against "Freedom". Not because I don't want it (I do), but because it conflicts with having a caring society, and it conflicts with the ability to be comfortably rich. America doesn't have a functional "health service for all" because that "freedom" interferes with the government's ability to provide it.
One only has to look at Twitter, where Elon's attempts to make it a haven of free speech has led to users fleeing (or being driven off) the platform, curtailing their ability to speak ...
The rule of two seems to be a fundamental law of nature ...
Cheers,
Posted Jan 13, 2023 11:47 UTC (Fri)
by lis (subscriber, #141132)
[Link]
Posted Jan 13, 2023 13:05 UTC (Fri)
by clump (subscriber, #27801)
[Link]
There are true absolutists that would champion positions even at the expense of other desirable outcomes. But actions speak louder than words, especially true with your final example.
Posted Jan 13, 2023 14:30 UTC (Fri)
by magnus (subscriber, #34778)
[Link]
Posted Jan 13, 2023 14:41 UTC (Fri)
by mikebenden (guest, #74702)
[Link] (3 responses)
Note that often you can only have *one* (of *two*), rather than 2 out of three, or whatever other combination. So, TL;DR, I'm not saying this stuff only to be pedantic, I genuinely wonder why "2 out of three" is apparently worth all this special attention, as a principle... :)
Posted Jan 13, 2023 18:22 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link]
We could probably argue this is really just two things, with safety being potentially achieved via lack of privilege or from the opposite perspective, lower privilege achieved via a safe language, whereas the untrusted inputs are a totally different category, so that the "rule" is really just don't allow both.
The "rule of two" is definitely more a vague intuition than a theorem we can expect somebody might prove.
Posted Jan 13, 2023 21:15 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Because I brought it up, and there's a "2 of 3" example (society) that's important to me? :-) I hadn't thought of "1 of 2" ...
Plus most people I think find a "1 of 2" situation easy to understand. It's fairly easy to see that if you want A, then B becomes not possible. It's much harder for people to grasp that if you want A, B, and C, that choosing A and B means C is impossible.
Cheers,
Posted Jan 14, 2023 1:46 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
* If there's fewer than three choices, then it's probably trivial, or at most a tradeoff that can be optimized by adjusting until everyone is equally (un)happy. These can still be highly controversial (abortion, affirmative action, etc.), but you just end up with typical left-right polarization in most cases.
Posted Jan 12, 2023 23:55 UTC (Thu)
by k8to (guest, #15413)
[Link] (15 responses)
I can't see how you can get the same benefits by using rust as you can by running code in separate processes. They seem complementary approaches, not one replacing the other.
I get the if you toss out multi-process you can jettison a bunch of logic, and that lowers maintenance burden, but I am skeptical that this is sufficient to entirely replace the security concerns addressed by process separation.
Posted Jan 13, 2023 1:09 UTC (Fri)
by rillian (subscriber, #11344)
[Link]
The security properties of memory/data-race safety and process isolation are of course quite different, so in a specific case one might be more useful than another. Or one might want both. It would also be great if `cargo deny` could check for certain syscalls to get some static enforcement of boundaries without hitting the sandbox. Chromium also has its own portability layers; at some point it will probably make sense to port the rust standard library to them so if a dependent crate did try to make e.g. a network or filesystem request, the normal policies and annotations would apply just like they do to internal C++ code.
Posted Jan 13, 2023 1:12 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
If you need this flexibility then you have no choice but to figure out a way to secure it, but if you don't need it, its existence might actually out weigh the risk from being in-process.
Posted Jan 13, 2023 20:02 UTC (Fri)
by bartoc (guest, #124262)
[Link]
I guess you do expose any issues with confusion in the IPC conventions themselves, that you avoid inproc because compilers know about the C calling convention and (attempt to) enforce things.
Posted Jan 13, 2023 5:46 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (7 responses)
"Untrusted inputs" is just one: not enough! Now stop separating processes and you get "high privilege" back! Back to 2.
This is obviously sarcasm but there's an element of truth: "too much" security means less productivity.
Posted Jan 13, 2023 18:05 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (6 responses)
People have competition (sometimes) and finite budget and deadlines (always). A very secure product that... does not exist is not very useful product.
So far secure products that don't exist have always lost the competition against hopelessly insecure products that do. There must be some explanation for that?
Also, guess what happens when security is too complex and too time consuming? "Only human" people get it wrong and it ends up... insecure!
I see SELinux raising its hand at the back of the room... a question maybe?
Posted Jan 13, 2023 20:04 UTC (Fri)
by bartoc (guest, #124262)
[Link] (5 responses)
Selinux is what a lot of the Android isolation model is based on, I think.
Posted Jan 14, 2023 16:17 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (4 responses)
It's different for locked down systems like Android that don't change and which can afford a full time security team, granted
Posted Jan 15, 2023 11:54 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
But we're in a Rust thread, Rust provides us exemplars of what you do about that, you make it easy/beautiful to do the safe thing and annoying/ugly to do the unsafe thing, and I think SELinux has been making some strides in that direction.
It would technically be possible to write equally unsafe nonsense for Chromium in Rust as in C++, it's just that in reality you won't because unsafe { *foo.get_unchecked_mut(n) = ... } is a lot of typing and looks ugly, whereas the C++ equivalent foo[n] = ... is easy to do and very tidy, shame it's a security disaster.
Posted Jan 15, 2023 16:17 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (1 responses)
Until you mentioned these examples, this thread was about complexity/productivity/security trade-offs.
Posted Jan 15, 2023 17:29 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link]
When I first encountered curl, the default was no name check. Today you need to specify a command line argument to turn the check off. That's not very much friction but it's some, the lazy option is safer. The earliest SQL frameworks I used had no provision for parameterized queries, today you won't really see that, the API you're introduced to is likely to have parameterisation. Rather than a complicated all purpose JSON parser with a dozen knobs and a forty page "tutorial" people are more likely to offer something that's as simple as eval() but without the foot gun.
Posted Jan 17, 2023 17:24 UTC (Tue)
by tchernobog (guest, #73595)
[Link]
Besides, for sure the most asked question is "how do I exit vim".
Posted Jan 13, 2023 19:44 UTC (Fri)
by geofft (subscriber, #59789)
[Link] (1 responses)
https://blog.chromium.org/2012/05/tale-of-two-pwnies-part... (2012) and https://securitylab.github.com/research/chromium-ipc-vuln... (2020) are worth reading, not just because they describe specific vulnerabilities but mostly because they give you a sense of how much complexity is really there in the IPC.
Sandboxing / address-space isolation is a great technique when the actual problem you're trying to solve is executing someone else's code, especially native or JITted code and browsers certainly do a good bit that (apart from JS, there's also stuff like calling the host's graphics-acceleration libraries). But there's a lot of attack surface in the browser that involves problems that aren't really shaped like executing code, like decompressing media or managing video capture or parsing HTML, and those are problems where you really should be able to write a memory-safe implementation - i.e., any bugs are just logic bugs and will just generate e.g. incorrect video output, which the attacker could have done directly by just sending a different video, and won't affect unrelated data structures in the same process. If you can get that guarantee, in theory you don't need process isolation, and in practice it makes sense to me that you'd get fewer bugs than by maintaining a process isolation layer.
Posted Jan 14, 2023 10:57 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
In a general purpose language it's necessarily possible that the intention of my program is to read 426 bytes from this JFIF data and use those to replace the running program code. I can do anything, that's the point of a general purpose language, so of course I must be able to do this very stupid thing.
But in WUFFS I can't write that, which is good because I never mean to write that. So like you said, if I screw up a WUFFS video decoder might produce incorrect video output, which is not what I wanted, but it's rarely valuable to attackers. WUFFS is not a competitor to a general purpose language, except in the sense that we shouldn't have been using general purpose languages for some of these things in the first place.
When you see stats about Android having C code in it, to my understanding some of that C code is WUFFS-the-library which is transpiled WUFFS and thus arguably much safer even than Rust code since most of Rust's safety rules are enforced by WUFFS at compile time, not runtime.
Posted Jan 14, 2023 20:23 UTC (Sat)
by flussence (guest, #85566)
[Link]
As is maybe obvious from its perpetual high speed security patch treadmill, that sandboxing isn't all that effective — and the simplicity argument isn't that compelling either, because it seems like they can't maintain the current codebase effectively enough to deliver features there's overwhelming demand for.
Posted Jan 17, 2023 17:39 UTC (Tue)
by wtarreau (subscriber, #51152)
[Link]
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
* unsafe implementation language; and
* high privilege.
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Wol
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Pareto Optimality (in 3D, in this particular case)
Pareto Optimality (in 3D, in this particular case)
Pareto Optimality (in 3D, in this particular case)
Wol
Pareto Optimality (in 3D, in this particular case)
* If there's more than three choices, then the Venn diagram gets much more complicated and there's probably no simple way to explain which combinations are or are not available. At that point, it's some esoteric "policy wonk" decision, not something the public is likely to hear about.
* If you can have all three, or zero, then it's trivial (unless there's controversy over which of those two outcomes is preferable, of course).
* If you can only have one, then you can just negate all three options and now you can only have two, so it's the same.
* If you can have exactly two, then there's just enough complexity that it's hard for the public to conceptualize unless they're specifically paying attention, so politicians can waste enormous amounts of time making things sound more complicated than they are. See for example Brexit and the Northern Ireland problem - you could frame it as a three-way tradeoff between the UK doing a softer Brexit than the Brexiteers wanted, a "soft-ish" border on the island of Ireland (controversial!), and a "soft-ish" border across the Irish sea (also controversial!) - but the politicians wasted so much time trying to avoid the trilemma, that they never seriously explored any of the problem space, and ended up landing on the 100% "border in the sea", 0% everything else solution by default, not because it was necessarily the best option (although it may well have been, depending on your politics), but because it was the only option that was left.
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development
Rust to be allowed for Chromium development