LightBlog

mercredi 22 août 2018

Google made a program to test security patch compliance on Android devices

Android Security Patch Bulletin

Security, mostly due to heavy software fragmentation, is one of the biggest issues with the Android ecosystem. Google's own Pixel smartphones aim to be the gold standard of secure Android smartphones, but the company doesn't only want to secure their own devices. Google has introduced measures like Project Treble, worked to extend LTS support of the Linux kernel from 2 to 6 years, introduced the Android Enterprise Recommended Program, and have even reworked their OEM agreements to start mandating regular security patches. But in an announcement posted today, the company has announced that they've been working on a new tool to ensure that smartphone device makers are complying with monthly security patch bulletins.

At Google I/O, Google's head of Android platform security, David Kleidermacher, announced that Google's Android partners are required to push regular security updates. In the announcement posted today, Google re-iterated that OEMs should roll out a security patch update at least once every 90 days in case of high severity vulnerabilities, while Android Enterprise Recommended devices must receive them at least once every 90-days. Monthly security updates are recommended and strongly recommended for commercially sold and Enterprise devices, respectively. Android One devices are required to receive monthly security patch updates, however.

But, just rolling out an update and calling it a day doesn't seem to be enough to keep users secure. This was proven when we heard allegations about manufacturers misrepresenting (perhaps intentionally) the state of the security patches that were rolled out to their devices. So, the question is, how do we ensure that OEMs comply with patching all vulnerabilities outlined in a monthly security bulletin? The answer is to make it easier for OEMs to do so.

In the past, all Android device makers, after merging the latest framework and vendors patches outlined in each monthly security patch bulletin, had to manually test whether their patches actually fixed the vulnerabilities the patches were intended to fix. This can be a long and not-really-straightforward process. Now, Google decided to make their work easier as they are releasing a program which will automate the testing process of the security patches. This will most likely be in the form of an automated CTS (Compatibility Test Suite) test that OEMs are required to pass for their updated build to be Google Play Certified. This will push smartphone makers to release security updates that comply with the security bulletin.

We have been developing security update testing systems that are now making compliance failures less likely to occur. In particular, we recently delivered a new testing infrastructure that enables manufacturers to develop and deploy automated tests across lower levels of the firmware stack that were previously relegated to manual testing. In addition, the Android build approval process now includes scanning of device images for specific patterns, reducing the risk of omission.

Google's Existing Security Measures in Android

This is the latest effort from Google to fix the security patch issues in the Android ecosystem. Previously, the company announced that with the partnership with the Linux Foundation, Linux kernel's Long-Term-Support (LTS) will be increased from 2 years to 6 years. The reasoning behind this decision was that most of the devices being released came with already outdated and discontinued versions of the Linux kernels because it was so hard to build, design, and ship the device within the 2-year window that Linux's LTS kernels offered. OEMs also don't have to backport security patches from the newer versions of the Linux kernel thanks to longer LTS.

In addition, Project Treble also made releasing security patches (and software updates in general) easier for OEMs. As you may already know, Project Treble modularizes the Android operating system framework so that implementing the newest security patch in the vendor and kernel can be done independently of patching the framework.

So, what are the goals of Project Treble, extended Linux kernel LTS, and automated security patch testing? One might think that it's more security updates, but it's actually the opposite. Google wants to improve the security of the Android to a level that security updates will be a rare necessity. But, the company also wants the manufacturers to be able to push the updates as soon as possible, should the occasion arise. Sure, as a short-term solution, it's nice if manufacturers don't miss a month without releasing the security update. But, in the long-term, it'd be nicer if there was not as much necessity of them as it is today.


Source: Android Developers Blog



from xda-developers https://ift.tt/2o0XH20
via IFTTT

Aucun commentaire:

Enregistrer un commentaire