{"id":50037,"date":"2018-09-24T14:32:44","date_gmt":"2018-09-24T14:32:44","guid":{"rendered":"http:\/\/www.sickgaming.net\/blog\/2018\/09\/24\/redefining-security-technology-in-zephyr-and-fuchsia\/"},"modified":"2018-09-24T14:32:44","modified_gmt":"2018-09-24T14:32:44","slug":"redefining-security-technology-in-zephyr-and-fuchsia","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2018\/09\/24\/redefining-security-technology-in-zephyr-and-fuchsia\/","title":{"rendered":"Redefining Security Technology in Zephyr and Fuchsia"},"content":{"rendered":"
<\/div>\n

If you\u2019re the type of person who uses the word \u201cvuln\u201d as a shorthand for code vulnerabilities, you should check out the presentation from the recent Linux Security Summit<\/a> called \u201c<\/span>Security in Zephyr and Fuchsia.\u201d In the talk, two researchers from the National Security Agency discuss their contributions to the nascent security stacks of two open source OS projects: Zephyr and Fuchsia. <\/span><\/span><\/p>\n

If you\u2019re worried about the fact that Edward Snowden\u2019s old employer is helping to write next generation OSes that could run our lives in 10 years, consider the upsides. First, since these are open source projects, any nefarious backdoors would be clearly visible. Second, the NSA knows a thing or two about security. Stephen Smalley and James Carter, who discussed security in Zephyr and Fuchsia, respectively, are <\/span>computer security researchers at the NSA\u2019s Information Assurance Research group<\/span>, which developed and maintains the security-enhanced SELinux and SE Android distributions. Smalley leads <\/span>the NSA’s Security Enhancements (SE) for the Internet of Things project and is a kernel and userspace maintainer for SELinux.<\/span><\/span><\/p>\n

The Linux Foundation hosted <\/span>Zephyr Project<\/span><\/a>, which is creating the IoT-oriented Zephyr RTOS, is the more mature of the two projects. Google\u2019s <\/span>Fuchsia OS<\/span><\/a> has a longer way to go — especially if you believe that <\/span>Fuchsia<\/span><\/a> will replace Android and Chrome OS over the next decade.<\/span><\/span><\/p>\n

The developers of Zephyr and Fuchsia have a rare opportunity to develop novel, up-to-date security stacks from scratch. One of the main reasons Google chose to build Fuchsia from a new microkernel was that it could avoid the hodgepodge of legacy code layered on top of Linux, thereby improving security. Attempts to <\/span>boost security in Linux<\/span><\/a> are always going to be like patching holes in a boat. Zephyr and Fuchsia aim to be the OS equivalents of hovercraft.<\/span><\/span><\/p>\n

Zephyr and Fuchsia are very different OSes, and they implement security in different ways. Zephyr is designed for constrained devices running on microcontrollers, such as Cortex-M4 chips, whereas Fuchsia will target phones and desktops running on applications processors, such as Cortex-A53 and Intel Core.<\/span><\/span><\/p>\n

\u201cZephyr and Fuchsia were both open sourced in 2016, but they have been developed for very different use cases,\u201d said Smalley. \u201cTheir architectures are very different, and each is also very different from Linux.\u201d<\/span><\/span><\/p>\n

Zephyr security<\/span><\/span><\/h3>\n

Like Linux and Fuchsia, Zephyr has RO\/NX memory protection, stack depth overflow prevention, and stack buffer overflow detection. However, there\u2019s still no kernel or user space ASLR (<\/span>address space layout randomization), which \u201c<\/span>will likely move to a build time randomization and a small boot time relocation,\u201d said Smalley. <\/span><\/span><\/p>\n

Among other architectural differences with Linux, \u201cThere\u2019s no process isolation in Zephyr, only a userspace thread model,\u201d explained Smalley. \u201cThe process abstraction model has yet to be implemented, and the kernel\/user boundary is still being fleshed out.\u201d<\/span><\/span><\/p>\n

In Zephyr, \u201cyou\u2019re generally working with a single application, and security is highly dependent on particular SoCs and kernel configurations,\u201d said Smalley. By comparison, \u201cIn Linux, there are a number of core OS security features that are neutral and independent.\u201d<\/span><\/span><\/p>\n

The original Zephyr release had a single executable with a single address space with all threads in supervisor mode and no memory protection or virtual memory, said Smalley. \u201cAs Zephyr added OS protections, it sought to minimize changes to kernel APIs in order to be backward compatible,\u201d he added. \u201cA key Zephyr design philosophy is to do as much as possible at build time, and then as much as possible at last view time, thereby minimizing runtime overheads and ensuring bounded latency for real-time.\u201d<\/span><\/span><\/p>\n

Zephyr security is complicated by the fact that some of the MCUs it targets include memory protection units (MPUs) while others do not. Beginning in releases 1.8 and 1.9, Zephyr began to provide memory protections, with allowances for both types of MCUs.<\/span><\/span><\/p>\n

The NSA team developed a set of kernel memory protection tests modeled on lkdtm tests from the <\/span>Kernel Self Protection Project<\/span><\/a> (KSPP) for Linux. \u201cThe tests were helpful in catching bugs in Zephyr MPU drivers, and they are now used for regression testing,\u201d said Smalley.<\/span><\/span><\/p>\n

Zephyr added userspace support in versions 1.10 and 1.11 that provided basic support for user mode threads with isolated memory. Smalley\u2019s team developed a set of userspace tests \u201cthat sought to validate the security properties for user mode threads were being enforced.\u201d \u00a0Zephyr\u2019s userspace memory model is still limited to a single executable and address space, and there\u2019s no virtual memory. \u201cIt can support user mode threads but not full processes,\u201d explained Smalley.<\/span><\/span><\/p>\n

Sign up to receive updates on Open Source Summit and ELC+OpenIoT Europe: <\/span><\/em><\/p>\n

Zephyr security features include an object permissions model in which user threads must first be granted permissions to an object to enable access. \u201cA kernel mode thread can grant access to a user mode thread, and an inheritance mechanism allows those permissions to be propagated down,\u201d explained Smalley. \u201cIt\u2019s an all or nothing model — all user threads can access all app global variables.\u201d<\/span><\/span><\/p>\n

This all-or-nothing approach \u201cposes a high burden on the application developer, who has to manually organize the application global variable memory layout to meet MPU restrictions,\u201d said Smalley. To help compensate, the NSA team developed a feature due in release 1.13 that \u201csupports a slightly more developer friendly way of grouping application globals based on desired protections. It\u2019s a small step forward, not a panacea.\u201d<\/span><\/span><\/p>\n

Future Zephyr security work includes adding MPU virtualization, which \u201cwould allow us to support a larger number of regions instead of just eight that can be swapped in and out of the MPU on demand,\u201d said Smalley. \u201cWe also hope to provide full support for multiple applications and program loading.\u201d <\/span><\/span><\/p>\n

In Zephyr, kernel code is fully trusted. \u201cWe would like to see Linux-like mitigations for kernel vulns using KSPP kernel self-protection features while minimizing runtime overheads,\u201d said Smalley. Other wish-list items include leveraging <\/span>armv8-m<\/span><\/a> for Cortex-M MCUs, thereby enabling <\/span>TrustZone security. There\u2019s also a long-term plan <\/span>to \u201cdevelop a MAC suited to RTOSes that\u2019s more oriented to build-time app partitioning.\u201d<\/span><\/span><\/p>\n

Fuchsia security<\/span><\/span><\/h3>\n

Fuchsia differs from Linux and Zephyr in that it\u2019s a <\/span>microkernel OS with security based on <\/span>object capability<\/span>. <\/span>Like Linux it offers process isolation. In addition, \u201cThe plumbing for kernel or user space ASLR is there,\u201d said the NSA\u2019s James Carter.<\/span><\/span><\/p>\n

Compared to the \u201clarge and monolithic\u201d Linux, Fuchsia has a small, decomposed TCB (trusted computing base),\u201d said Carter. \u201cIt also uses object capabilities instead of DAC and MAC.\u201d <\/span><\/span><\/p>\n

Fuchsia is based on the Zircon Microkernel, which is derived from the little kernel (lk), \u201can RTOS used in the Android bootloader,\u201d explained Carter. Fuchsia extends lk to support 64-bit, user mode, processes, IPC, and other advanced features. \u201cThe lk is the only thing that runs in supervisor mode. Drivers, filesystem, and network all run in user mode.\u201d<\/span><\/span><\/p>\n

Fuchsia security mechanisms include regular handles and resource handles using Zircon object capabilities. \u201cRegular handles are usually the only way that userspace can access kernel objects,\u201d said Carter. \u201cFuchsia differs from most OSes in that it uses a push model in which a client creates the handle and pushes it to a server. Handles are per-process and unforgeable, and they identify both the object and a set of access rights to the object. Access rights include duplicating them with equal or lesser rights or passing them across IPC or using them to obtain handles to child objects with equal or lesser writes.\u201d<\/span><\/span><\/p>\n

Fuchsia handles \u201care good because they separate rights for propagation vs. use and separate rights for different operations,\u201d said Carter. \u201cYou can also reduce rights through handle duplication.\u201d<\/span><\/span><\/p>\n

Handles still pose some problems, however. For example, \u201cwith object_get_child(), if you have a handle to a job, you can acquire a handle to anything in that job or any child jobs,\u201d said Carter. \u201cAlso, a leak of root job handle is fatal to security. We\u2019d like to see more work on making everything able to be least privilege, and more control over handle propagation and revocation. Not all operations currently check access rights and some rights are unimplemented.\u201d<\/span><\/span><\/p>\n

Resource handles, which are the type of handle used for platform resources like memory mapped I\/O, I\/O ports, and IRQs, let developers specify the type of resource and optional range. On the plus side, they offer \u201cfine-grained, hierarchical resource restrictions,\u201d said Carter. \u201cHowever, right now the root resource check isn\u2019t very granular, and as with regular handles, leaks can be fatal. We need to work on propagation, revocation, and refining to least privilege.\u201d<\/span><\/span><\/p>\n

Zircon security primitives include job policy and vDSO enforcement. \u201cIn Fuchsia everything is part of a job,\u201d said Carter. \u201cProcesses don\u2019t have child processes \u2013 jobs have child jobs. Jobs can be nested, containing jobs and other processes, and job policy is applied to all processes within the job. Policies are inherited from the parent and can only be made more restrictive.\u201d<\/span><\/span><\/p>\n

On the pro side, you can create fine-grained object creation policies, as well as hierarchical job policies that are mixed,\u201d explained Carter. \u201cHowever, the <\/span>W^X<\/span><\/a> policy is not yet implemented, and when it is it will cause problems with strict hierarchical policies because if a child needs to map something W^X, then all ancestors would need to beta map it W^X as well.\u201d<\/span><\/span><\/p>\n

In Fuchsia, the <\/span>vDSO<\/span><\/a> (<\/span>virtual dynamic shared object) primitive \u201c<\/span>is only meant to invoke system calls,\u201d said Carter. \u201cIt\u2019s fully read-only and is mapping constrained by the kernel.\u201d<\/span><\/span><\/p>\n

Fuchsia\u2019s vDSO makes the OS more secure by \u201climiting the kernel attack surface, enforcing the use of the public API, and supporting per process system call restrictions,\u201d said Carter. \u201cIt\u2019s also good that vDSO is not trusted by the kernel so its system call arguments are fully validated.\u201d On the other hand, the current version offers the potential for tampering with or bypassing vDSO, added Carter. <\/span><\/span><\/p>\n

Carter went on to explain Fuchsia namespaces and sandboxes. Advantages of the namespaces implementation include \u201cthe lack of a global namespace and the fact that object reachability is determined by initial namespace,\u201d said Carter. \u201cBut we\u2019d like to see more granularity.\u201d For sandboxes, which are used for isolating applications, \u201cWe\u2019d like to see an expansion to system services. There\u2019s also no independent validation of the sandbox configuration.\u201d<\/span><\/span><\/p>\n

As with Zephyr, the NSA team recommends that Fuchsia eventually add a MAC framework, which would help to \u201ccontrol propagation, support revocation, and apply least privilege,\u201d said Carter. \u201cA MAC could support finer grained check and generalize job policy, as well as validate namespaces and sandboxes. It could also provide a unified framework for defining, enforcing, and validating security goals.\u201d<\/span><\/span><\/p>\n

Options for integrating a MAC with Fuchsia start with building it entirely in user space with no microkernel support, said Carter. Alternatively, you could \u201cextend the existing mechanism\u201d by building it \u201cmostly in user space with limited microkernel support.\u201d A third choice would be to \u201ccreate security policy logic in user space with full microkernel enforcement for its objects, as we did with DTMach in SELinux.\u201d<\/span><\/span><\/p>\n

In conclusion, Carter emphasized that Fuchsia\u2019s security stack is <\/span>a work in progress. \u201cWe\u2019re just trying to evaluate the thing.\u201d You can watch the entire video below.<\/span><\/span><\/p>\n

[embedded content]<\/p>\n","protected":false},"excerpt":{"rendered":"

If you\u2019re the type of person who uses the word \u201cvuln\u201d as a shorthand for code vulnerabilities, you should check out the presentation from the recent Linux Security Summit called \u201cSecurity in Zephyr and Fuchsia.\u201d In the talk, two researchers from the National Security Agency discuss their contributions to the nascent security stacks of two […]<\/p>\n","protected":false},"author":2,"featured_media":50038,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40],"tags":[],"class_list":["post-50037","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux-freebsd-unix"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/50037","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=50037"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/50037\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media\/50038"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=50037"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=50037"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=50037"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}