Google so far hasn't shown much knowledge of endpoint security, uses many stacks with huge attack surface, and plays penetrate/patch. That's from their web services all the way to mobile. Third parties, both companies and FOSS types, are doing better at protecting Android than Google. Although there's exceptions, Google seems mostly unqualified or uncaring in terms of strong INFOSEC.
So, I have little trust in the security of ARTOS or Vault for now. I tried to review the ARTOS kernel's design but they pulled it off their site. So, we have nothing to go on but their word. I can't wait to get some more objective information about its design and implementation for a real review.
> Google so far hasn't shown much knowledge of endpoint security, uses many stacks with huge attack surface, and plays penetrate/patch.
[citation needed]
> Third parties, both companies and FOSS types, are doing better at protecting Android than Google.
such as...?
> Although there's exceptions, Google seems mostly unqualified or uncaring in terms of strong INFOSEC.
Eh? What's your basis for this claim? They are pretty much always on the latest & greatest. ECHDE_RSA, certificate pinning, universal 2nd factor (FIDO), strong sandboxing & permissions (you may not remember, but those were things Google took mainstream with Chrome & Android). Google's also the company that took security vulnerability rewards and made that a thing.
Plenty of things to dislike Google about (privacy is always an easy target, for example), but security really isn't one of them. They have one of the best trackrecords you can have here.
While Android is in pretty bad shape, I'd still give Google some credit, they have been slowly starting to improve their OS security in the last 2 years. But quite a few early design choices favouring performance over security, such as Zygote rendering ASLR ineffective, are lingering and holding back Android's security.
They are also using Linux kernels from 2012 or earlier (3.4) on almost all devices, although from what I've heard that is mostly the fault of vendors such as Qualcomm moving slowly.
Good for you. We Android users appreciate people picking up Google's slack. :) It looks like your people are mixing the regular hardening advice with some ported stuff from BSD/Linux security work. This is low-medium in that it won't stop serious attackers if you get popular. Yet, even baking in the basic hardening by default should reduce risk of many real-world attacks. The other stuff might do more in final form. Keep at it.
Having read a few of your other comments I'd be curious to hear your thoughts on ways in which we could harden Android (on here or via email).
Our focus now is indeed adding memory protections to the underlying OS, to get Android up to date with at least 2004-era exploit mitigation. Before moving on to higher-level stuff :)
Linux is so inherently insecure that it's hard to say without processor & toolchain modifications. What you can do is follow lead of the others: combine a microkernel (eg OKL4, OC.L4) with paravirtualized Android with security-critical components running outside of Android. The Nizza Architecture [1] below illustrates this. A better, but commercial, approach [2] shows how to handle drivers and some other things better. It's been deployed in a ridiculous number of phones with success. So, standardize on a phone, audit/test the crap out of the drivers, put an OKL4/Nizza-style architecture on it, and pull out anything security-critical to run on microkernel with careful input validation & state management. Should reduce TCB, increase reliability, and prevent spoofing if you fully implement Nitpicker for mobile. Hope that helps.
Quick note: be sure to clear all internal registers and cache if kernel transitions from trusted software to untrusted software if you're worried about covert channels (esp key leaking). Both of those can leak keys to professionals if they compromised the Android portion.
Zygote is more about memory than performance, and that's still a needed thing. SELinux is in enforcing mode and has an increasingly tighter and tighter net.
Also Google is using 3.10 on the devices they sell, not 3.4. What Samsung, HTC, etc... ship is a different story, but that's not under Google's control.
First part: name one high assurance system Google has ever produced or a low assurance system that top tier hackers gave up on? Did their mobile OS have a strong TCB with POLA on the apps and trusted path? Did their web services use native code (minimal attack surface) with checks manually or automatically built in to stop most attacks? Did they perform a covert channel analysis on their cryptographic stuff? Do they know what those are unlike many INFOSEC types I meet? Has anything they designed used an architecture that made leaks or code injection nearly impossible? If not, then my statement stands until Google demonstrates the ability to make a secure product or one that approximates that. They haven't caught up to Daniel Bernsteins' Qmail claims much less top-tier work like KeyKOS [1] or Burroughs [2]. Ancient, top tier work...
Re third parties. There are numerous academic teams doing hardware or compiler work on making Linux-based systems immune to code injection or at least isolated. OK Labs did OKL4 with user-mode Android for isolation. Samsung leveraged INTERGITY microvisor in Knox. Perseus Security Framework did something similar with a Linux personality, modified by Sirrix or SYSGO I believe for mobile. Control-pointer integrity does this on hardware supporting segments (x86). DIFT catches when incoming data screws with pointers and such, also ported to Linux. Automated diversification and keyed hardware SOC's to make Linux probabilistically secure. Several methods ported to Linux to stops leaks or injection with crypto tricks. Many things Google could've used for mobile and non-mobile. NSA did SEAndroid. Then there's Tor, modders, and Android developers tools/tips to lock down Android and turn off Google's leaks. About everyone but Google did great work in securing Android.
To test you on your own claims, would you trust a vanilla Android installation's security out of the box or make some modifications first? I'd mod it or assume I'm game for whoever.
re unqualified in strong INFOSEC
Everything you mention they, like IT in general, built on foundations of quicksand: low assurance hardware, firmware, and software that has regularly been defeated by skilled hackers. So, sure they pushed some good security technologies that stop low to mid-grade hackers or solve pieces of the puzzle (see my use of "exceptions"). Yet, Google themselves and their Android users were hacked with quite vanilla techniques due to their system and software architecture. There are systems in EAL6/7 and under SPOCK program that NSA pentesters couldn't breach despite having 2+ years to try. Matasano said something similar about Secure64's SourceT OS, too. The things they have in common is bottom-up, end-to-end, medium-to-highly assured (EAL6+) lifecycle. That's strong requirements, design, implementation, analysis, testing, build, configuration, and independent verification of that. Google hasn't done (censored) in this area despite having the brains to do so. Matter of fact, their smartest work IIRC was Native Client and it was smashed because they intentionally weakened the security model for performance reasons.
Almost all their stuff has been knocked down by serious hackers or subversions. It's why they needed the bug bounty. Smart idea if you're pushing low to mid grade throughout your whole stack. Didn't stop the Chinese and NSA from smashing them. They didn't even need esoteric techniques. The definition of high assurance security is the level of rigorous security engineering needed to resist well-funded, sophisticated threats with time on their hands. They never came close, so why do you trust them to do it now without proof? Trust, but verify.
I'd have to have its full details in front of me. Given how netbooks usually work, I'll hit you with a few questions and review it further if you have secure answers. Does it use regular firmware for its hardware or firmware hardened against attack? Are the drivers isolated in user-mode? Is the trusted software verified by eye, tool, or both to avoid all known code injections? Was that verified by third parties? Does it avoid software with huge TCB and many vulnerabilities such as Linux? Does it avoid Web apps and tech such as Flash?
If yes to all of these, then it's a start on strong security and definitely worth reviewing if only to help close remaining holes. Otherwise, it's probably already received a number of patches and not worth a review. Which is it?
From a political standpoint I don't know how many people would trust a Google product with security. Just the brand does not jive with the idea of security. Perhaps the product is good, I don't know. But FUD is in order considering the brand and its general past actions.
I agree. The Snowden leaks showing they're tight with NSA can't help that, either. I'll go further, though, with my main privacy argument against companies such as Google: the incentives of an ad-driven company are 100% opposite of privacy-seeking users. Expecting Facebook, Google, Yahoo, etc to protect one's privacy is ludicrous as they get more money for each privacy violation if not convicted in court.
The only kind of company that can be even semi-trusted is one that where you are the paying customer and their contract + host country's laws protect your privacy/security. Even more so if they have to contractually or legally pay huge fines for negligence. Align the incentives, then there's potential. If opposite incentives, turn 180 degrees and start running.
So, I have little trust in the security of ARTOS or Vault for now. I tried to review the ARTOS kernel's design but they pulled it off their site. So, we have nothing to go on but their word. I can't wait to get some more objective information about its design and implementation for a real review.