Last week, James Carter and Stephen Smalley presented the architecture and security mechanisms of two operating systems, Zephyr and Fuchsia at the Linux Security Summit 2018. James and Stephen are computer security researchers in the Information Assurance Research organization of the US National Security Agency (NSA).

They discussed the current concerns in the operating systems and their contribution and others to further advance security of these emerging open source operating systems. They also compared the security features of Zephyr and Fucshia to Linux and Linux-based systems such as Android.

Zephyr

Zephyr is a scalable real-time operating system (RTOS) for IoT devices, supporting cross-architecture with security as the main focus. It targets devices that are resource constrained seeking to be a new "Linux" for little devices.

Protection mechanisms in Zephyr

Zephyr introduced basic hardware-enforced memory protections in the v1.8 release and these were officially supported in the v1.9 releases. The microcontrollers should either have a memory protection unit (MPU) or a memory management unit (MMU) to support these protection mechanisms.

These mechanisms provide protection by the following ways:

They enforce Read Only/No Execute (RO/NX) restrictions to protect the read-only data from tampering.

Provides runtime support for stack depth overflow protections.

The researchers’ contribution was to review the basic memory protections and also develop a set of kernel memory protection tests that were modeled after subset of lkdtm tests in Linux from KSPP. These tests were able to detect bugs and regression in Zephyr MPU drivers and are now a part of the standard regression testing that Zephyr performs on all future changes.

Userspace support in Zephyr

In previous versions, everything ran in a supervisor mode, so Zephyr introduced a userspace support in v1.10 and v1.11. This requires the basic memory protection support and MPU/MMU. It provides basic support for user mode threads with isolated memory.

The researchers contribution, here, was to develop userspace tests to verify some of the security-relevant properties for user mode threads, confirm the correctness of x86 implementation, and validate initial ARM and ARC userspace implementations.

App shared memory: A new feature contributed by the researchers

Originally, Zephyr provided an access to all the user threads to the global variables of all applications. This imposed high burden on application developers to,

Manually organize application global variable memory layout to meet (MPU-specific) size/alignment restrictions.

Manually define and assign memory partitions and domains.

To solve this problem, the researchers developed a new feature which will come out in v1.13 release, known as App Shared Memory, having features:

It is a more developer-friendly way of grouping application globals based on desired protections.

It automatically generates linker script, section markings, memory partition/domain structures.

Provides helpers to ease application coding.

Fucshia

Fucshia is an open source microkernel-based operating system, primarily developed by Google. It is based on a new microkernel called Zircon and targets modern hardware such as phones and laptops.

Security mechanisms in Fucshia

Microkernel security primitives

Regular handles: Through handles, userspace can access kernel objects. They can identify both the object and a set of access rights to the object. With proper rights, one can duplicate objects, pass them across IPC, and obtain handles to child objects.

Some of the concerns pointed out in regular handles are:

If you have a handle to a job, you can get handle to anything in the job using object_get_child()

Leak of root job handle

Refining default rights down to least privilege

Not all operations check access rights

Some rights are unimplemented, currently

Resource handles: These are a variant of handles for platform resources such as, memory mapped I/O, I/O port, IRQ, and hypervisor guests.

Some of the concerns pointed out in resource handles are:

Coarse granularity of root resource checks

Leak of root resource handle

Refining root resource down to least privilege

Job policy: In Fucshia, every process is a part of a job and these jobs can further have child jobs. Job policy is applied to all processes within the job. These policies include error handling behavior, object creation, and mapping of WX memory.

Some of the concerns pointed out in job policies are:

Write execute (WX) is not yet implemented

Inflexible mechanism

Refining job policies down to least privilege

vDSO (virtual dynamic shared object) enforcement: This is the only way to invoke system calls and is fully read-only.

Some of the concerns pointed out in vDSO enforcement are:

Potential for tampering with or bypassing the vDSO, for example, processs_writes_memory() allows you to overwrite the vDSO

Limited flexibility, for example, as compared to seccomp

Userspace mechanisms

Namespaces: It is a collection of objects that you can enumerate and access.

Sandboxing: Sandbox is the configuration of a process’s namespace created based on its manifest.

Some of the concerns pointed out in namespaces and sandboxing are: