How do the Linux kernel memory protection features on Android work?

Google recently unveiled new Android security measures, which includes memory protection for the Linux kernel within…


* remove unnecessary class from ul
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);

* Replace “errorMessageInput” class with “sign-up-error-msg” class
function renameErrorMsgClass() {
$(“.errorMessageInput”).each(function() {
if ($(this).hasClass(“hidden”)) {
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
} else {

* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
function validateThis(v, form) {
var validateReturn = urValidation.validate(v, form);
return validateReturn;

* DoC pop-up window js – included in moScripts.js which is not included in responsive page
$(“#inlineRegistration”).on(“click”,”a.consentWindow”, function(e) {, “Consent”, “width=500,height=600,scrollbars=1”);

the OS. How is the memory protection provided, and why is it so important for Android?

The Linux kernel — the heart of an operating system — plays a major role in Android’s security model. This makes it a prime target for attackers as any vulnerability in the kernel can potentially give a hacker access to, if not complete control over, the system. The kernel’s various tasks live within one address space, meaning a vulnerability anywhere in the kernel can potentially impact unrelated portions of the system’s memory. Unlike processes running under the user space, which have access only to a limited part of memory, the kernel has access to all memory. This makes it vital to protect access to the kernel and kernel memory, and to maintain the integrity of the kernel in the face of any vulnerabilities.

As part of the ongoing work to improve Android, the Android Security Team recently implemented various attack surface reductions and enabled various memory protection mechanisms. The key memory protection feature is called Mark Memory As Read-Only/No-Execute. This feature segments kernel memory into isolated, logical sections and sets restrictive page access permissions on each section. Areas used to store code are marked as read-only plus execute, so only existing code can be read and executed while preventing new code, such as an attacker’s malicious payload, from being written into these spaces. Data sections are marked as no-execute and further segmented into read-only and read-write sections. As some data sections need to be written to, they are marked no-execute, so even if an attacker manages to write code to one of these sections it still can’t execute. There are additional restrictions on the kernel’s access to certain portions of user space memory to further limit the amount of control that an attacker has over executable kernel memory. The latest version of Android, Android 7.0 Nougat, will also include a better protection mechanism against stack buffer overflows.

To run Nougat, devices will have to support “seccomp,” an application sandboxing mechanism in the Linux kernel, which restricts processes to four main system calls, isolating it from system resources and reducing the kernel’s attack surface. Also, as most third-party apps don’t need access to input/output control (IOCTL) commands, only a small whitelist of socket IOCTL commands will be available. This should reduce the number of drivers that inadvertently expose the kernel to attack.

As well as kernel memory protections, the Android team has hardened the kernel by reducing the number of entry points and the attack surface, including removing default access to debug features. Debugging tools usually give developers elevated privileges and access to system resources that are normally off-limits. In Android Nougat, the operating system will block access to the “perf” debug tool by default to prevent malware taking advantage of the built-in debug features. One new change worth a mention is a standardized set of system Certificate Authorities (CAs), safer defaults and easier APIs for configuring how apps trust custom CAs. Trust can be specified across the whole app or only for connections to certain domains. This should prevent the growing abuse of digital certificates by malware and hackers attempting man-in-the-middle attacks.

Next Steps

Learn about the security improvements made to Android for Work in Nougat

Find out if Android Nougat’s features make it ready for the enterprise

Discover if Google’s Certificate Transparency tool can improve certificate security

Dig Deeper on Wireless Network Security: Setup and Tools

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever’s puzzling you.

Source link