Least Privilege Separation Kernel

Safety & Security for the Connected World

Using a Separation Kernel to Protect against the Remote Exploitation of Unaltered Passenger Vehicles

16th June 2015 Mark Pitchford, Technical Manager, EMEA Today’s hot topic

 A few years ago, Lynx presentations at events such as this centred on why domain separation is key

 And then…

http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

http://illmatics.com/Remote%20Car%20Hacking.pdf

 Fast forward to today, and hypervisors are now held aloft as the solution to the challenges presented by these issues

 Let’s start with a simpler example than a connected car

 Suppose we want a heart pacemaker to be able to report any irregularities back to a medical specialist.

 The primary role of the hypervisor here is to separate the “safe” and “unsafe” sides of the network

 Separation is key!

 But what of the separation mechanism itself?

 Because this is a shared resource, it is imperative that it is as secure as possible.

 If a vehicle is to be optimally protected, the attack surface exposed to would-be aggressors needs to be minimised. – Separate high ASIL systems from those of lower criticality – Separate the TCP/IP stack away from the vulnerability of the gateway’s OS

 If they are to truly be separated rather than conjoined, we also need to minimize the resources – and hence the attack surface - shared between these entities

 Microkernel RTOS

 Type 1 Hypervisor

 Least Privilege Separation Kernel

Microkernel RTOS Microkernel RTOS

 Microkernel technology has its roots in an era predating hardware virtualization

 Back then, there were two privilege levels to consider – Supervisor and user privilege levels

 The Microkernel approach included some far sighted principles – Executed vulnerable code (such as the TCP/IP stack) in User Space, not Supervisor Space.

• Then the Enterprise world brought us Hardware Virtualization…

Source: IDC

…which has now also found a home in the Automotive sector on multi-core ARM Cortex-A based SoCs (e.g. the NXP S32V series)

 What’s an engineer to do?

 Ignore the additional VMM privilege level? – That would present a very vulnerable and unprotected attack surface

 Increase the privilege level of the microkernel and associated services? – That would see some software running at a higher privilege level than necessary

 Either way – not an ideal gestation

Type 1 Hypervisor Type 1 Hypervisor

 Consider KVM; an example from the Open Source Ecosystem which illustrates a wider issue – Kernel-based Virtual Machine (KVM)

 KVM is a virtualization infrastructure for the Linux kernel that turns it into a hypervisor*

 KVM makes use of hardware virtualization to support that hypervisor functionality

*https://en.wikipedia.org/wiki/Kernel-based_virtual_machine

 This is a valid approach if the primary aim is to provide a hypervisor

 It is less attractive if the primary aim is separation

 KVM Linux exposes a minimum of 390 interfaces with hundreds of thousands parameter options implemented by 19.5 million lines of constantly changing code

 That code must be trusted to uphold VM isolation

Guest OSs Services Apps

API VM Monolithic Monitor Application Access Virtual I/O Policy Kernel CPU Scheduler Control

Resource Mgmt Interrupt Handler I/O Stack

Exception Handler Device Drivers - Storage, Network, Graphics…

• “Separate the TCP/IP stack away from the vulnerability of the gateway’s OS” • Shared Resources = Large Attack Surface

17 (c) Lynx Software Technologies. 2016. Type 1 Hypervisor

 This underlying “helper OS” cannot and does not present – An optimal separation solution – A minimised attack surface

 For that, we have to return to the classroom and understand the principles of Least Privilege and Separation Kernels

The Least Privilege Separation Kernel Hypervisor Least Privilege Separation Kernel Hypervisor

 First mooted by John Rushby in 1981

 Consists of a “combination of hardware and software that permits multiple functions to be realized on a common set of physical resources without unwanted mutual interference”

 Basic foundation of the Multiple Independent Levels of Security (MILS) initiative – a vision of modular building blocks for high-assurance secure systems

 40-year-old concept (Saltzer and Schroeder)

 Per-subject and per-resource flow-control granularity – No subject needs to be given more access than that required to allow the desired flows

Saltzer, J.H. and Schroeder, M.D. The Protection of Information in Operating Systems. Proceedings of the IEEE 63(9):1278-1308. 1975

SMP Safety Cert POSIX RTOS POSIX RTOS Linux Support for existing environments & applications

Apps Apps Apps Apps Apps Apps

Other Linux Android AUTOSAR Bare Bare Metal RTOS Metal Components LSA LSA FV/PV FV/PV FV/PV Component FV FV/PV FV

Hardware

23 (c) Lynx Software Technologies. 2016. Trusted Computing Base (TCB)

 Still a Separation kernel – NOT a cut down RTOS!

Secure Update Gateway V2x Gateway Entertainment Gateway

Firmware App App Server VM Server Server

LSA. connect Tunneled Virtual Networks

AUTOSAR LynxOS V2x Linux Encrypted Disk Partitions VM VM VM LSA.store VM V-NIC V-Disk V-NIC V-Disk V-NIC V-Disk Image Disk Network Manager VM Gateway VM VM Image

VM Image

 The combination of a separation kernel and hypervisor offers – Domain isolation, real-time determinism and high availability – Flexibility of application environments to bring legacy and modern OS environments – Bare-metal applications for safety and security

 The combination of a least-privilege separation kernel hypervisor and a modern multi-core processor represents the state-of- the-art to achieving separation in software

Thank You