
The Rule of 2 - akendo
https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
======
tyingq
_" If you can be sure that the input comes from a trustworthy source"_

Perl's _" taint"_[1] capability is pretty interesting in this space. Do other
languages have something similar?

[1] [https://perldoc.perl.org/perlsec.html#Taint-
mode](https://perldoc.perl.org/perlsec.html#Taint-mode)

 _" You may not use data derived from outside your program to affect something
else outside your program--at least, not by accident. All command line
arguments, environment variables, locale information (see perllocale), results
of certain system calls (readdir(), readlink(), the variable of shmread(), the
messages returned by msgrcv(), the password, gcos and shell fields returned by
the getpwxxx() calls), and all file input are marked as "tainted"."_

Unrelated rant: Sometime recently mobile chrome omits any part of a url after
a # when you copy/share the url. Grrr.

~~~
realharo
I'm not aware of a similar feature built into other languages, but most of it
could be easily achieved with almost any type system.

Just have two separate types, e.g. UnsafeString and regular String, and some
kind of `convert` function that takes a validation function as an argument.
You'd get compile-time checking that way.

People don't tend to use such things in practice though, and you would also
have to ban a portion of most language's standard libraries to enforce it in
practice (because they already return regular strings for inputs).

~~~
aidos
This can be a useful pattern - though I’ve never seen it used for this
usecase. A similar one is templating languages (like Jinja) where you need to
wrap strings if you want to send HTML to your templates with them being
escaped on render.

We use something similar where we have a BadNumber class in our code (python).
Any operation with another number will also create a BadNumber. It allows us
to make sure that these tainted numbers are always obvious.

------
est31
> The Rule Of 2 is: Pick no more than 2 of

> * untrustworthy inputs;

> * unsafe implementation language; and

> * high privilege.

> Security engineers in general, very much including Chrome Security Team,
> would like to advance the state of engineering to where memory safety issues
> are much more rare. Then, we could focus more attention on the application-
> semantic vulnerabilities. That would be a big improvement.

> Unsafe implementation languages are languages that lack memory safety,
> including at least C, C++, and assembly language. Memory-safe languages
> include Go, Rust, Python, Java, JavaScript, Kotlin, and Swift

Very nice. At the end of the process, Google might adopt Rust in Chromium. As
much as I use and love Firefox, it's only realist to say that Chrome has
higher chances of being around in 10 years.

I wonder why the list doesn't include their wuffs language.

~~~
tyingq
_" Memory-safe languages include Go, Rust, Python, Java, JavaScript, Kotlin,
and Swift"_

An interesting list. They left out C# and PHP if it's supposed to be the most
popular languages.

~~~
pjmlp
Selective view based on in house languages.

~~~
jchw
I work at Google and as far as I know Rust is not really “in house” at Google,
at least not any more than C#. Both languages exist in some form, Google does
have some plugins for Unity and I believe Fuchsia has some Rust code. It is
indeed unclear what criteria was used to select languages, though it’s really
not very relevant to the primary point anyway.

(Legal line noise: my opinions are not those of my employer.)

~~~
sitkack
Rust has been pulled into the Android tree.

~~~
jchw
That's genuinely exciting to hear. Thanks for letting me know.

------
oconnor663
> But if you transform the image into a format that doesn‘t have PNG’s
> complexity (in a low-privilege process, of course), the malicious nature of
> the PNG ‘should’ be eliminated and then safe for parsing at a higher
> privilege level. Even if the attacker manages to compromise the low-
> privilege process with a malicious PNG, the high-privilege process will only
> parse the compromised process' output with a simple, plausibly-safe parser.

It's interesting to get a sense of how deeply unrealistic they think it is, to
write a safe parser for a typical data format in an unsafe language.

~~~
pjmlp
Because as of 2019 the same errors as in early 1980's keep being repeated,
regardless how many tools have been developed to tame C and it's derivatives.

It is so unrealistic that Android is following up Solaris footsteps.

Google has announced that ARM memory tagging extensions will be required in
future Android versions.

~~~
MrMorden
When is Google going to require monthly security patch delivery?

~~~
pjmlp
Soon it seems.

According to an interview they gave to Are in 2017 about changing Play Store
contract.

And the new Project announced at IO to require support for GSI images.

------
johnday
Two actually seems like a lot here. Why would you angle for two and not one?
It seems like the latter two (unsafe implementation language and high
privilege) are both within the purview of developers. Is it just a case of
resource management?

~~~
skybrian
It's practical advice for Chrome developers wanting to get a patch accepted.
Deciding to rewrite the high-privilege parts of Chrome in Rust (say) is too
big a project to be in scope.

------
kazinator
How about rule of 3:

\- untrustworthy inputs

\- privilege

\- unsafe language

\- big, ball-of-mud codebase

We _can_ do the first three, if the thing is small and simple.

Pretty much every OS kernel out there in wide deployment has all four of the
above, though.

------
abalaji
Does anyone have a working link to the diagram at the top? It seems to be a
Google Drawing that requires permission to view/

------
emilfihlman
Image is broken.

~~~
jandrese
It's hosted off of a private google drive.

------
Vogtinator
"unsafe implementation language" is a pretty moot point.

Looking at all the trivial exploits against web applications which are
basically never written in memory-unsafe languages (Ruby, Python, PHP, ...)
shows that it doesn't really matter much. While having the same implementation
in a memory unsafe language would be slightly less safe, it's very unlikely
that a heap corruption could be exploited remotely.

~~~
pjmlp
Morris Worm.

About 70% of CVE reported exploits are due to memory corruption.

Living with the remaining 30% would already be a huge security improvement.

~~~
Vogtinator
The Morris Worm happened back when security was not really a big concern.

Memory corruption is much harder (and in most cases realistically not at all)
to exploit beyond a DoS, and that's what you would get with "safe" languages
such as Rust or Python as well.

Heartbleed, Shellshock, Dirty COW etc. would all happen exactly the same way
in different programming languages.

Yes, there is clearly a benefit in using something which makes it much harder
introducing memory safety issues, but it's not nearly as big as many here on
HN think.

~~~
missblit
Didn't Heartbleed rely on reading uninitialized data? I'd assume memory safety
includes preventing code from reading uninitialized data.

~~~
staticassertion
Yes, and correct.

