5 min read
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 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 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
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:
- Sandbox only for application packages (and not system services)
- Namespace and sandbox granularity
- No independent validation of sandbox configuration
- Currently uses global /data and /tmp
To address the aforementioned concerns the researchers suggested a MAC framework. It could help in the following ways:
- Support finer-grained resource checks
- Validate namespace/sandbox
- It could help control propagation, support revocation, apply least privilege
- Just like in Android, it could provide a unified framework for defining, enforcing, and validating security goals for Fuchsia.
This was a sneak peek from the talk. To know more about the architecture, hardware limitations, security features of Zephyr and Fucshia in detail, watch the presentation on YouTube: Security in Zephyr and Fucshia – Stephen Smalley & James Carter, National Security Agency.