Towards a Secure IoT Computing Platform Using Linux-Based Containers Marcus Hufvudsson Information Security, master's level (120 credits) 2017 Luleå University of Technology Department of Computer Science, Electrical and Space Engineering Abstract The Internet of Things (IoT) are small, sensing, network enabled computing devices which can extend smart behaviour into resource constrained domains. This thesis focus on evaluating the viability of Linux containers in relation to IoT devices. Three research questions are posed to investigate various aspects of this. (1) Can any guidelines and best practices be derived from creating a Linux container based security enhanced IoT platform? (2) Can the LiCShield project be extended to build dynamic, default deny seccomp configurations? (3) Are Linux containers viable on IoT platforms in regards to operational performance impact? To answer these questions, a literature review was conducted, research gaps identified and a research methodology selected. A Linux-based container platform was then created in which appli- cations could be run. Experimentation was conducted on the platform and operational measurements collected. A number of interesting results was produced during the project. In relation to the first research question, it was discovered that the LXC templating code created could probably benefit other Linux container projects as well as the LXC project itself. Secondly, it was found that a robust, layered containerized security architecture could be created by utilizing basic container configurations and by drawing from best practices from LXC and docker. In relation to the second research ques- tion, a proof of concept system was created to profile and build dynamic, default deny seccomp configurations. Analysis of the system shows that the developed method is viable. In relation to the final research question; Con- tainer overhead with regards to CPU, memory, network I/O and storage was measured. In this project, there were no CPU overhead and only a slight per- formance decrease of 0.1 % on memory operations. With regards to network I/O, a speed decrease of 0.2 % was observed when a container received data and utilized NAT. On the other hand, while the container was sending data, a speed increase of 1.4 % was observed while the container was operating in bridge mode and an increase of 0.9 % was observed while utilizing NAT. Regarding storage overhead, a total of 508 KB base overhead was added to each container on creation. Due to these findings, the overhead containers introduce are considered negligible and thus deemed viable on IoT devices. Contents 1 Introduction 1 1.1 IoT Classification . .2 1.2 Powerful IoT Use-Cases . .6 1.3 Introduction to Containers . .8 1.4 Problem Statement . .9 1.5 Research Questions . 10 1.6 Research Objectives . 10 1.7 Expected Contributions . 11 1.8 Delimitations . 11 1.9 Thesis Outline . 12 2 Background 13 2.1 Linux-Based Containers . 13 2.2 Linux Kernel Features . 14 2.2.1 Namespaces . 15 2.2.2 Root File System . 16 2.2.3 Cgroups . 17 2.2.4 Capabilities . 18 2.2.5 Secure Computing Mode . 19 2.2.6 Linux Security Modules . 20 3 Related Work 22 3.1 Container Security Studies . 22 3.2 Container Performance Studies . 25 3.3 Comparative Study . 30 3.4 Research Gap . 31 4 Research Methodology 34 4.1 Methodology Implementation . 36 4.1.1 Problem Identification and Motivation . 36 4.1.2 Definition of the Objectives for a Solution . 36 4.1.3 Design and Development . 37 4.1.4 Demonstration . 37 4.1.5 Evaluation . 37 4.1.6 Communication . 38 5 Design 39 5.1 Phase One - IoT Container Platform . 39 5.2 Phase Two - Dynamic Seccomp Profiling . 40 5.3 Phase Three - Container Performance Measurements . 40 5.4 Project Overview and Planning . 41 6 Implementation 43 6.1 Phase One - IoT Container Platform . 43 6.1.1 Base Operating System . 45 6.1.2 LXC Container Platform . 45 6.1.3 UTS Namespace . 48 6.1.4 Networking Namespace . 48 6.1.5 Mount Namespace . 49 6.1.6 Root File System . 49 6.1.7 Cgroups . 50 6.1.8 Capabilities . 51 6.1.9 Secure Computing Mode . 52 6.2 Phase Two - Dynamic Seccomp Profiling . 54 6.2.1 First Iteration . 55 6.2.2 Second Iteration . 55 6.2.3 Third Iteration . 57 6.3 Phase Three - Container Performance Measurements . 61 7 Results 63 7.1 Phase One - IoT Container Platform . 63 7.1.1 Base Operating System . 63 7.1.2 LXC Container Platform . 64 7.1.3 UTS Namespace . 65 7.1.4 Networking Namespace . 65 7.1.5 Mount Namespace . 66 7.1.6 Root File System . 67 7.1.7 Cgroups . 67 7.1.8 Capabilities . 68 7.1.9 Secure Computing Mode . 68 7.2 Phase Two - Dynamic Seccomp Profiling . 69 7.3 Phase Three - Container Performance Measurements . 70 7.3.1 CPU & Memory Operation Measurements . 70 7.3.2 Network Measurements . 71 8 Discussion 79 9 Conclusions 84 9.1 Future Work . 85 Chapter 1 Introduction The term Internet of Things was, according to Sundmaeker et al. [1] first mentioned by the founders of the MIT Auto-ID center. The term was then picked up by various news organizations. In 2005, the International Telecom- munications Union (ITU) published a report on the IoT concepts and its meaning. Sundmaeker et al. [1] summarizes the ITU's report on the mean- ing of IoT: "The ITU report adopts a comprehensive and holistic approach by sug- gesting that the Internet of Things will connect the world's objects in both a sensory and intelligent manner through combining technological develop- ments in item identification ("tagging things"), sensors and wireless sensor networks ("feeling things"), embedded systems ("thinking things") and nan- otechnology ("shrinking things")." In essence, the definition boils down to relatively small devices (compared to the more common traditional computers) which has the ability to com- municate with other devices. The smart devices that is IoT has steadily been making progress into society and will most likely continue to do so. Aerospace, automotive, telecommunication, housing, medical, agriculture, retail, processing industries and transportation are just some examples of industries that have seen adoption of IoT [1]. A diverging aspect of the IoT concept compared to traditional comput- 1 ing is its inherent heterogeneous nature. IoT devices can range from small identification tags (RFID), simple sensors and actuators to smart and more powerful, distributed intelligence devices (or even a mixture of all of them). These different types of devices must often interact with each other to pro- vide a meaningful function. One example of how these various heterogeneous devices could work together to form a system is given by Atzori et al. [2]. In their health care example: tracking, identification/authentication, data collection and sensing are used in conjunction in order to provide services needed in the domain. Tracking with the help of RFID systems could for ex- ample be useful to identify the location of a patient. Similarly, identification could be used to associate medication to the patient and data collection could be performed by an intermediary device to which sensor nodes are attached which keep track of the patient's status. 1.1 IoT Classification Bormann et al. [3] has proposed a set of terms to be used in the IoT domain. This thesis makes use of some of these terms to facilitate a common ground for the definition of the work presented. In their paper, Bormann et al. define a "constrained node" by comparing it to a node operating on the Internet. In this context, an "Internet node" could for example be a server, or laptop. In contrast to an Internet node, a constrained node is one that costs less and/or exhibit "physical constraints on characteristics such as size, weight, and available power and energy" [3]. These constraints leads to lower expectations of the constrained device. Bormann et al. recognizes that this definition is not very rigorous. It does however offer a relativistic definition that will always points toward significantly less powerful devices than what is currently the state of the art technology used in Internet nodes. Bormann et al. [3] further exemplifies the definition of a constrained node by providing a list of typical facets exhibited: • constraints on the maximum code complexity (ROM/Flash) • constraints on the size of state and buffers (RAM) 2 • constraints on the amount of computation feasible in a period of time ("processing power") • constraints on the available power • constraints on user interface and accessibility in deployment (ability to set keys, update software, etc.) The first two items in this list, "code complexity (ROM/Flash)" and "size of state and buffers (RAM)" is used to further define three specific classes of constrained nodes in order to further extend and understand the definition. Bormann et al. provides a table of the different classes. Table 1: Classes of Constrained Devices [3] Name data size (e.g., RAM) code size (e.g., Flash) Class 0 <<10 KiB <<100 KiB Class 1 ∼ 10 KiB ∼ 100 KiB Class 2 ∼ 50 KiB ∼ 250 KiB As can be seen in table 1, a constrained node differs significantly from an Internet node in terms of memory capacity. This table is constructed based on "commercially available chips and design cores for constrained devices" [3]. Bormann et al. notes that the boundaries of table 1 will change over time as technology progresses and maybe it already have since this thesis is written three years after [3] was published. The advent of "single board computers", such as the Raspberry Pi [4] could very well have skewed the table. Although, this is just speculation.