xRAC: Execution and Access Control for Restricted Application Containers on Managed Hosts

TL;DR

xRAC introduces a secure, container-based approach for running restricted applications on managed hosts, enabling controlled access to network resources while maintaining compatibility with existing infrastructure.

Contribution

The paper presents xRAC, a novel system using standard virtualization and network protocols to enhance security and access control for restricted application containers.

Findings

xRAC effectively isolates applications with unique IPv6 addresses.

The implementation requires minimal modifications to existing infrastructure.

Experimental validation confirms performance and security benefits.

Abstract

We propose xRAC to permit users to run special applications on managed hosts and to grant them access to protected network resources. We use restricted application containers (RACs) for that purpose. A RAC is a virtualization container with only a selected set of applications. Authentication verifies the RAC user's identity and the integrity of the RAC image. If the user is permitted to use the RAC on a managed host, launching the RAC is authorized and access to protected network resources may be given, e.g., to internal networks, servers, or the Internet. xRAC simplifies traffic control as the traffic of a RAC has a unique IPv6 address so that it can be easily identified in the network. The architecture of xRAC reuses standard technologies, protocols, and infrastructure. Those are the Docker virtualization platform and 802.1X including EAP-over-UDP and RADIUS. Thus, xRAC improves network security without modifying core parts of applications, hosts, and infrastructure. In this paper, we review the technological background of xRAC, explain its architecture, discuss selected use cases, and investigate on the performance. To demonstrate the feasibility of xRAC, we implement it based on standard components with only a few modifications. Finally, we validate xRAC through experiments.

Full text

I Introduction

In this paper we consider the problem of permitting users to run special applications on managed hosts and to grant them access to protected network resources. This is an important challenge in practice as applications communicate with multiple peers and have multiple, possibly a priori unknown flows characterized by 5-tuples. Moreover, common packet filters such as firewalls or deep packet inspectors lack knowledge of allowed flows, and identifying traffic from specific applications becomes more difficult with traffic encryption using TLS.

We address this challenge by running applications in containers as so-called \acprac on managed hosts. \acprac provide selected sets of applications including their dependencies and configuration. The managed host gives users only limited freedom, e.g., they can download and launch \acprac. We propose \acaa for \acprac so that their execution is restricted to authorized users. That means, the user identity, the integrity of the \acrac’s image, and the permission of the user to execute the \acrac are verified before a \acrac is launched. We suggest to extend this authorization also to protected network resources required by the \acrac, e.g., to internal networks, servers, or Internet access. That means, appropriate network control elements, e.g., firewalls or SDN controllers, may be informed about authorized \acprac and their needs. The authorized traffic can be identified by the \acrac’s IPv6 address. We call this concept xRAC as it controls execution and access for \acprac.

We mention a few use cases that may benefit from xRAC. \acprac may allow users to execute only up-to-date \acrac images. Execution of a \acrac may be allowed only to special users or user groups, e.g., to enforce license restrictions. Only selected users in a high-security area may get access to the Internet through a \acrac-based browser which is isolated from the remaining infrastructure. Only selected users may be able to execute administration software with access to servers providing confidential material. \acprac may be used for applications with increased \acqos requirements, e.g., voice-over-IP, video conferences, or games. Their traffic may be preferentially treated by network elements.

To facilitate deployment of xRAC, we reuse and adapt standard technologies, protocols, and infrastructure. We leverage the Docker platform to create and deploy containerized applications. When the \accmd is requested to launch a \acrac, it first issues an \acaa request and launches the \acrac only after successful \acaa. We adopt 802.1X for \acaa purposes and adapt its components 802.1X supplicant (802.1X S), 802.1X authenticator (802.1X A), and 802.1X authentication server (802.1X AS). The \accmd interfaces with an \ac8021x-cs on the host, the \ac8021x-cs with a \ac8021x-ca, and the \ac8021x-ca with an \ac8021x-as. The \ac8021x-as holds \acrac-specific \acaa data, performs authentication, and returns authorization data to the \ac8021x-ca. The \ac8021x-ca interfaces with network control elements and configures access to network resources depending on authorization data. It also forwards the authorization data to the \ac8021x-cs. EAP-over-UDP and RADIUS are utilized for communication. To demonstrate the feasibility of xRAC, we provide a prototype based on existing 802.1X components, implement the \ac8021x-cs as plugin for the Docker authorization framework and the \ac8021x-ca as part of an SDN controller. We use a RADIUS server for \ac8021x-as and extend its data structures to store \acaa data for users and \acsrac. We use this prototype to experimentally validate xRAC in a testbed.

The rest of the paper is structured as follows. In Section II, we review technical background and related work on container virtualization. In Section III, we review technical background and related work on 802.1X and \acaa for applications. In Section IV, we present the architecture of xRAC in detail. Section V discusses use cases along benefits and limitations of xRAC. Section VI describes the prototypical implementation of xRAC which is used for its experimental validation in Section VII. In Section VIII, we briefly investigate on performance considerations of xRAC. Section IX concludes this work.

II Container Virtualization: Technical Background and Related Work

We first introduce the concept of container virtualization, describe advantages and give an overview of Docker as a widespread implementation. Then, we review container security platforms and containers for GUI applications.

II-A Overview

Containers implement virtualization on the \acos level. They provide virtualized \acos environments that are isolated with regard to hardware resources and security. They share the \acos kernel and may include binaries and libraries that are required to run one or several enclosed applications. In xRAC, we enclose only one special application with its dependencies and configuration in a container. Containers run on top of a container runtime and are managed by a \acfcmd that creates, starts and suspends containers. Examples for container platforms are Docker [1], Kubernetes [2], BSD jails [3], and Solaris containers [4].

II-B Advantages

Virtualization facilitates efficient and flexible usage of hardware resources, improves security through isolation, and provides fault-safety and scalability through simple migration processes. Containers in particular have the following additional advantages. Due to the shared \acos, containers require less CPU, memory, and hard disk resources. Container images are much smaller than virtual machines, which simplifies distribution among many recipients. Containers simplify application deployment. Instead of providing support for complex combinations of applications, dependencies, and user configurations, administrators just deploy containers that are tested prior to release. Containers have no bootup times, which makes them especially suitable for short-lived applications.

II-C Docker Container Virtualization Platform

Docker [1] is one of the most popular container platforms today. Figure 1 provides a simplified overview of the Docker platform including its operations. A host with a common \acos runs the Docker \accmd that generates and manages containers and container images. Container images are write-protected templates that include applications with their dependencies. Containers are runtime instances that extend the write-protected container images by a writeable layer. Therefore, multiple container instances may share a common image. This introduces scalability with low hard disk requirements. The Docker \accmd is controlled by the Docker client via a REST interface. The Docker client can be located on the host running the Docker \accmd or on a remote host. The Docker \accli is an example for user control through \accli calls. The Docker \accmd may connect to Docker registries that allow users to upload (push) or download (pull) container images. Those registries are either private or publicly available. Docker Hub [5] with more than 100.000 container images is an example for the latter. Common operations are build (1), pull (2), and run (3). With build, users may create individual container images. With pull, users may download container images from a repository to become part of the set of local images. With run, container images from the set of local images can be executed on the host system.

Docker uses several functions of the \acos kernel [7, 8, 9, 10] to provide isolation and resource emulation. It supports storage drivers, e.g., AuFS [11], OverlayFS [12], and ZFS [13], to enable file system stacking. The container format and runtime environment of Docker were adopted by the Open Container Initiative [14] as open industry standard.

II-D Container Security Platforms

Container security platforms extend the \accmd by security functions. Twistlock [15, 16] and the Aqua Container Security Platform [17] provide a runtime engine based on machine learning mechanisms to permanently monitor containers for detecting fraudulent behavior and special network firewalls to filter container traffic. The Sysdig Secure [18] platform allows the formulation of service-aware policies, i.e., policies that are based on applications, containers, hosts, or network activities. The platform provides alerts and actions based on policy violations, an event history, and incident captures. The Atomicorp Secure Docker Kernel [19] is a hardened Linux kernel that provides security-related features such as break-out protection, memory corruption protection, or prevention of direct userland access by the kernel. All platforms focus on monitoring and controlling potentially untrustworthy containers that are executed on a shared container runtime. Features for \acaa for users, containers, and their network flows are not part of those platforms.

The Docker Authorization Framework [20] is part of Docker since Version 1.10 [21]. It extends the Docker \accmd by a REST interface to external authorization plugins. Requests from the Docker \accmd, e.g., to start a container, are forwarded to an authorization plugin that implements mechanisms to decide whether to allow or deny the request. The Docker Authorization Framework does not implement security functions but provides a base for implementing such security concepts. xRAC leverages this framework.

II-E Containers for GUI Applications

Containers typically deploy applications or services without \acpgui that run in the cloud or on data center infrastructures. Examples are containers that enclose web applications with their requirements, e.g., an nginx webserver with a PHP runtime and a MySQL database server. The idea of leveraging Docker containers to deploy desktop applications with a \acgui was first presented in [22]. The author proposes to mount X11 sockets for \acgui presentation and hardware devices of the host system, e.g., an audio card or a web camera, to the Docker container. Thereby, even more complex \acgui applications such as the Chrome web browser, the Spotify music player, or the Skype video chat application can be run in containers and be deployed as container images. Today, many Docker container images with \acgui applications can be downloaded from Docker Hub.

III 802.1X: Technical Background and Related Work

We give an overview of 802.1X and explain how it supports \acaa. We present EAPoUDP which is an alternative protocol to carry \acaa data in 802.1X. We summarize how \acaa for applications is currently performed in practice and review another research work that provides \acaa for applications based on 802.1X.

III-A Overview

IEEE 802.1X [23, 24, 25] introduces port-based network access control in wired Ethernet networks. However, it is mainly known from wireless 802.11 networks today. An example is Eduroam [26], a federation of wireless university campus networks. Participants can connect to the Internet no matter if located at their home institution or at a foreign university campus, e.g., while attending a conference.

Figure 2 depicts the three components of 802.1X and the principle of port-based network access control. The supplicant system is a network host that contains the \ac8021x-s. The authenticator system contains the \ac8021x-a and controls network access of network hosts. Examples are access switches that connect network hosts to the main network. Prior to authorization, the supplicant system can reach the \ac8021x-a but not the network. The \ac8021x-as is an authentication, authorization, and accounting server. It stores authentication data to verify user identities and authorization data to grant permission to the network. It authenticates the \ac8021x-s and delivers authorization information to the \ac8021x-a.

III-B \acaa with 802.1X

802.1X leverages the \aceap [27] and the \acradius [28] to exchange \acaa data. Both provide a fixed request and response scheme to exchange \acaa data. The Diameter protocol [29] is a less widespread alternative. Authentication data is transmitted in Ethernet frames as \aceapolan encapsulation between the \ac8021x-s and \ac8021x-a and as \aceaporadius between the \ac8021x-a and \ac8021x-as. Figure 4 depicts the packet structure of \aceapolan. Authorization data is transmitted in \acradius frames between the \ac8021x-as and \ac8021x-a.

We explain the details of 802.1X with the four-step process of \acaa as depicted in Figure 3. In the first step (1), the \ac8021x-s initializes authentication by sending an EAPOL-Start message to the \ac8021x-a. In the second step, the \ac8021x-a requests the identity from the \ac8021x-s (2a) and forwards it to the \ac8021x-as (2b). \acradius supports large domains that consist of many hierarchically organized \acradius servers. Each identity is associated with a domain and known by the \acradius server of that domain so that \acaa attempts can be forwarded in \acradius infrastructures. In the third step (3), authentication is performed between the \ac8021x-s and \ac8021x-as. The authenticator decapsulates \aceap packets from \aceapolan frames and reencapsulates them as \aceaporadius frames and vice versa. The flexible message structure of \aceap allows the use of different authentication procedures. Simple approaches carry plain-text identity information or simple MD5-hashed passwords, but more secure authentication procedures like EAP Tunneled TLS [30] and EAP-TLS [31] are also supported. The authenticator only relays \aceap messages in pass-through manner. Therefore, new \aceap types only need to be implemented on the \ac8021x-s and \ac8021x-as but not on the \ac8021x-a. In the fourth step, the \acradius server may return authorization data after successful authentication to the \ac8021x-a (4a). It can be coarse-granular, e.g., a binary access decision whether the supplicant system gets access or no access, or fine-granular, e.g., VLAN tags [32] to be set for prospective user traffic or filter rules [33] that are applied by the authenticator. The authenticator applies the authorization data on the particular physical port of the switch, e.g., it sets a VLAN tag. Afterwards, the authenticator confirms successful \acaa to the supplicant with an EAP-Success message (4b).

III-C \acfeapoudp

\ac

eapoudp is a variation of \aceap that allows transmission of EAP data over UDP and IP. Figure 4 depicts its packet structure in comparison to EAPoL. In contrast to \aceapolan, \aceapoudp can be used to authenticate multiple applications that run on a network host. Also, UDP packets can be transmitted over any link layer technology or even routed within multi-domain networks. \Aceapoudp was introduced as Internet draft [34] that expired without standardization in the PANA working group of the IETF in 2002. Cisco leveraged \aceapoudp in its Trust Agent [35] tool that runs on network hosts and interacts with Cisco NAD, a prorietary network control system. The Trust Agent collects host system information, interfaces host software, and delivers notifications to network hosts within \aceapoudp frames. xRAC leverages \aceapoudp for frontend authentication.

III-D AA for Applications in Practice

802.1X focuses on port-based access control for network hosts. In practice, \acaa for applications is implemented as part of the application or with the help of Kerberos.

Most network applications implement some form of \acaa mechanism. Examples are login forms in the launch window where users are required to enter valid credentials to start using the applicaton. Other examples are client certificates that are used in conjunction with TLS and a public key infrastructure. However, \acaa functionalities that are part of the application have an impact that is limited to the client and server side of the network application. Neither the start of the application nor the network infrastructure in between can be controlled.

Kerberos [36, 37] is a network authentication protocol that provides mutual authentication for clients and servers over an insecure network. Clients are entire hosts, users, or applications; servers represent hosts that offer particular network applications. Kerberos adapts user tickets for authentication for various network applications. Kerberos needs to be implemented by applications on client and server side, which prevents its application for legacy applications that cannot be modified. Again, neither the start of kerberized applications nor the network infrastructure in between can be controlled.

III-E AA for Applications with FlowNAC

FlowNAC [38] introduces a fine-granular SDN network access control system that adapts 802.1X for \acaa of applications on network hosts. To enable multiple \acaa for different applications on a network host, the authors introduce EAPoL-over-EAPoLAN encapsulations. As depicted in Figure 4, FlowNAC introduces another variation of EAPoL. An EAPoL-in-EAPoL packet field identifies up to 64K different EAP processes that are transmitted as encapsulated EAP payloads. However, this deviation from legacy 802.1X requires major changes of the \ac8021x-s and \ac8021x-a. The \ac8021x-s is part of an \acos’s kernel, the \ac8021x-a is part of network switches so only open source \acpos and firmwares allow modifications. Nevertheless, it is difficult to carry on the modifications in new versions of the \acos’s kernel or firmware image. The authors rely on \aceapolan, i.e., \acaa data transfer is limited to the Ethernet link. \aceapoudp would solve those shortcomings but was not considered in the work. Unlike xRAC, FlowNAC neither introduces IP addresses for applications nor restricts the start of applications by \acaa.

IV xRAC Architecture

In this section, we first explain \acprac and give an overview of xRAC. Then, we explain the operation of its three control components in details.

IV-A Restricted Application Containers (RACs)

\acp

rac are executable container images that enclose a single application, its dependencies, and configuration data such as program settings or software licensing information. As depicted in Figure 5, \acprac are executed on a container runtime in parallel to \acos-native applications. The \accmd controls the execution of \acprac and provides an interface for users to create, delete, start, or stop \acprac. Each \acrac has a unique IPv6 address so that its traffic can be easily identified in the network. \acrac images are created by network administrators and deployed via \acrac registries. They are either downloaded from those registries by users or automatically synchronized to managed hosts.

IV-B Overview of xRAC

xRAC provides execution and access control for \acprac on managed hosts. A \acrac needs to be authenticated and authorized before launching. Figure 6 depicts the \acaa process for \acprac with 802.1X. First, a user attempts to start a \acrac via the \accmd (1), and the \accmd requests the \ac8021x-cs for \acaa (2). After successful authentication (3), the \ac8021x-as responds with authorization data via the \ac8021x-ca (4) to the \ac8021x-cs (4a). The \ac8021x-cs notifies the \accmd to launch the \acrac (4b). In addition, the \ac8021x-ca informs network control elements about the authorized \acrac. In our example, it configures the firewall to permit access to the proteced server (4c). Other examples are SDN controllers that program SDN switches. Now, the authorized \acrac but not the managed host or other \acprac can communicate with the protected server (5).

\Ac

aa for \acprac introduces two additional advantages to common application deployment and network security. First, \acaa of \acprac restricts \acrac launches on managed hosts to predefined \acrac images and permitted users. This allows network operators to ensure that only up-to-date and unmodified \acrac images can be launched. This improves computer and network security as only valid \acrac images can be executed on the managed hosts. In addition, network operators may deploy \acrac images to managed hosts in advance, e.g., by synchronizing their set of \acrac images with an internal \acrac repository in the background. Users have all available \acrac images on managed hosts but are only able to start them if they become authorized after \acaa. Last, each \acrac has a globally unique IPv6 address that can be used to identify and steer all traffic originating from a particular \acrac. \acrac authorization data on the \ac8021x-as includes information on how the \acrac’s traffic should be steered by network elements that can be applied by network control elements.

IV-C 802.1X Authentication Server (802.1X AS)

The authentication request from the \ac8021x-cs to the \ac8021x-as contains user and container authentication data (UAND, CAND). The 802.1X AS authenticates the user and verifies the integrity of the RAC image. If the RAC image is valid, and if the user is authenticated, and if the user has permissions to run the RAC, the 802.1X AS responds to the 802.1X CA with authorization data. To perform that decision, the 802.1X AS requires a new data model which is depicted in Figure 7. It consists of user profiles (1), \acrac profiles (2), and groups (3) that define whether a particular user is permitted to run a particular \acrac. User profiles (1) contain \acuand that is used to authenticate the user. Examples are user credentials, e.g., user names and passwords. \acrac profiles (2) contain \accand and \accazd. The first is used to verify the integrity of the \acrac through calculating the cryptographic hashing function over the \acrac image. \accazd include all permissions of a \acrac, i.e., to be started by the requesting user and to utilize network resources. In the depicted example, the \acrac is allowed to access a specified network resource. The \acaa data for the described model is stored on the \ac8021x-as. The data model is an example that can be easily extended to support other requirements.

IV-D 802.1X Container Supplicant (802.1X CS)

The \ac8021x-cs authenticates \acprac with the \ac8021x-as via the \ac8021x-ca. It transmits \acuand and \accand to the \ac8021x-as and receives \accazd from the \ac8021x-ca.

Figure 8(a) illustrates the process of \acaa from the perspective of the \ac8021x-cs. It runs on the managed host, interfaces the \accmd, and is configured with the IP address or URL of the \ac8021x-ca so that it can initiate \acaa. In (1), the user requests the \accmd to start a particular \acrac on the managed host. The request includes \acuand. The \accmd requests the \ac8021x-cs to permit the user’s demand (2). The request includes \acuand and \accand collected by the \accmd. The \ac8021x-cs initiates \acaa by establishing an \aceapoudp session with the \ac8021x-ca. Afterwards, it performs authentication with the \ac8021x-as via the \ac8021x-ca (3). Backend authentication is performed via \aceaporadius while frontend authenticated is performed via \aceapoudp as in legacy 802.1X. In case of successful authentication, the 802.1X CS receives CAZD from the 802.1X CA (4). Then, the 802.1X CS permits the CMD to start the RAC (5).

IV-E 802.1X Container Authenticator (802.1X CA)

The 802.1X CA relays AA data between the 802.1X CS and the 802.1X AS. Moreover, it informs network control elements about authorized RACs.

In step (1) of Figure 8(b), authentication data are transported over EAP between 802.1X CS and 802.1X AS. Between 802.1X CS and 802.1X CA, the EAP data are carried over UDP (EAPoUDP) and between 802.1X CA and 802.1X AS, they are carried over RADIUS. Thus, one task of the 802.1X CA is to modify the tunnel for EAP data. Moreover, after successful authentication the 802.1X AS returns CAZD over RADIUS to the 802.1X CA (2) which then informs the 802.1X CS about successful authorization (3a). While the conventional 802.1X A just opens ports on a switch for authorized devices, the 802.1X CA may also inform other network control elements about authorized RACs. Those may be ports on a switch, firewalls (3b), or SDN controllers (3c). The firewall is then programmed to pass through all outbound traffic with the RAC’s IP address and the SDN controller instructs SDN switches to forward all traffic with the RAC’s IP address appropriately. More specific flow descriptors are not needed.

V Use Cases and Discussion

We discuss two exemplary use cases of xRAC and discuss its benefits and limitations.

V-A Use Case I: Web Browsers in High-Security Areas

Research departments, state departments, or clinics dealing with highly sensitive data isolate their internal networks from the Internet. However, web browsers are still required for online research activities. We propose to deploy web browsers as \acprac on managed hosts. The isolation of \acprac prevents that malicious users may misuse the Internet access to leak internals or contaminate the internal network through infectious downloads, e.g., PDF documents that include a trojan or virus. The network flow control of \acprac ensures, that only the web browser can reach the Internet. If the \acrac’s traffic is encrypted, e.g., DNS queries and web site data, network control elements can still perform packet filtering based on the IP addresses of the \acrac.

V-B Use Case II: Confidential Data Access

Applications dealing with confidential data, e.g., research activities, medical documentation, or law enforcement, often access servers with confidential data. If such applications are deployed as RACs on managed hosts, only legitimate users have access to those servers. The isolation feature of RACs prevents remote hackers from attacking the server. Normally, they get system access through gateways provided by viruses or trojans received as browser downloads or e-mail attachments which is not possible with \acprac. Furthermore, malicious users of legitimate applications may use hacker tools to gain access to the server and to leak information from it, which is not possible in the digital domain with an isolated application. The isolation of \acprac prevent malicious users or applications from attacking the server. The network flow control ensures that the server can be reached only by legitimate \acprac and users but not by other \acprac or the managed host itself.

V-C Benefits of xRAC

xRAC inherits the advantages generally known from virtualization and container virtualization that we have discussed in Section II-B. In addition, xRAC can guarantee that only valid containers are launched on managed hosts and that they can be used only by legitimate users. Thus, xRAC performs AA for applications without the need to modify them, which is a particular benefit for legacy applications. Moreover, the 802.1X CA can configure network control elements such that authorized RACs have access to protected network resources. RACs facilitate this control as all traffic of a RAC is identified by a single IPv6 address. This is a particular benefit as in today’s networks there is no information about legitimate flows, many application flows may have the same IP address, and applications may even be invisible due to encryption using TLS. Thus, steering traffic from legitimate or trusted applications is a tough problem for which xRAC provides a solution. xRAC is flexible as it implements software-defined network control by interacting with other network control elements. In particular, it does not depend on and is not limited to specific technologies.

V-D Limitations of xRAC

xRAC requires a managed infrastructure where the managed host, its CMD, and the 802.1X components, i.e., 802.1X CS, 802.1X CA, and 802.1X AS, are trusted. Encapsulating applications in RACs complicates access to shared resources so that xRAC may be cumbersome or infeasible for some use cases.

VI Prototypical Implementation

In the following, we describe a prototypical implementation of xRAC. We overview the testbed environment and describe all components in detail.

VI-A Testbed Environment

Figure 9 depicts the testbed environment. The managed host executes \acprac. The SDN switch connects the managed host, the protected web server, the public web server and is controlled by an SDN controller. The SDN controller runs the \ac8021x-ca as SDN application that communicates with an \ac8021x-as.

We leverage nested virtualization, i.e., one \acvm encapsulates all parts of the testbed environment including the managed host. This approach allows the entire testbed to be migrated to other hardware platforms for further work and experiments. We use the KVM hypervisor [39] with QEMU [40] for hardware-assisted virtualization and libvirt [41] for orchestration. The managed host, both web servers, and the RADIUS server run as nested \acpvm with Ubuntu 17.04 [42]. Open vSwitch [43] serves as SDN switch that is controlled by the Ryu SDN controller [44].

VI-B Docker as Container Virtualization Platform for \acprac

We use Docker [1] in Version 17.05 as container virtualization platform to implement \acprac. We configure the Docker \accmd so that each \acrac gets a dedicated IPv6 global unicast address that is reachable by other network hosts. Figure 10 depicts the applied networking configuration that follows the approach presented in [45]. By default, \acprac only receive a link-local IPv6 address. Therefore, we set up a fixed IPv6 subnet with routable addresses for \acprac. The managed host is configured with the IPv6 subnet 2001:db8::11:0/116 and the \acprac receive an IPv6 address from that range. The first \acrac receives 2001:db8::11:1 and the second \acrac 2001:db8::11:2, respectively. The Docker daemon automatically adds routes to the routing table of the system and enables IPv6 forwarding so that all traffic to the IPv6 subnet will be routed via the docker0 interface. To make the \acprac reachable from other network hosts, we leverage the NDP proxy daemon [46]. It forwards L2 address resolution for IPv6 addresses of the \acprac, i.e., it listens to neighbour solicitation requests for the \acprac addresses and answers with the MAC address of the managed host. Afterwards, packets that address a \acrac are received and forwarded through the Docker host via the docker0 device to the particular \acrac.

VI-C 802.1X Container Supplicant (802.1X CS)

We implement the \ac8021x-cs as plugin for the Docker Authorization Framework introduced in Section II-D. We program the plugin in Python and leverage the Flask [47] library to implement its REST interface. Figure 11 depicts the authorization process. In (1), the user requests the \accmd to start a container. The request includes \acuand, e.g., a user name and a password. The Docker Authorization Framework predefines a two-step authorization process, but we only require the second step. The first authorization request (2) includes only minimal data, e.g., the name of the \acrac image. As we solely rely on the second authorization step, the \ac8021x-cs responds with a permit by default. The second authorization request (3) includes \acuand and \accand. The \ac8021x-cs performs authentication with the \ac8021x-as through the \ac8021x-ca (3) as discussed before. In (4), \ac8021x-as returns \accazd that is forwarded to the \ac8021x-cs in case of successful \acaa.

VI-D 802.1X Container Authenticator (802.1X CA)

We implement the \ac8021x-ca as SDN application for the Ryu SDN controller framework [44]. We extend the \ac8021x-a of [48] by adding support for authentication with the \ac8021x-cs using \aceapoudp. The \ac8021x-ca opens a UDP socket on port 5995 and waits for connections from the \ac8021x-cs. The \ac8021x-ca still may act as legacy \ac8021x-a that performs \acaa for network hosts in legacy 802.1X via \aceapolan. As example for network control with xRAC, we implemented a restricted MAC-learning switch. It learns MAC addresses from connected hosts but only forwards packets if the IP addresses of both sender and receiver are in a whitelist. The whitelist contains static entries, e.g., for public servers, and dynamic entries that can be modified by the \ac8021x-ca after receiving \accazd from the \ac8021x-as. We implement the restricted MAC-learning switch by extending the L2 switch [49] from the Ryu SDN controller framework.

VI-E 802.1X Authentication Server

We leverage the widely-used \ac8021x-as software FreeRADIUS and extend its \acaa data model to implement \accand and \accazd. In FreeRADIUS, additional attributes for \acaa and simple policies can be implemented using \acpvsa [28, 50, 51, 52] that are defined with the unlang [53] processing language. The defined \acaa data model can be easily extended and modified by adding more \acpvsa.

VI-F Protected and Public Web Server

Two web server \acpvm in the testbed environment run a Python web server [54] that provides HTML files via HTTP. The protected web server with the static IPv6 address 2001:db8::aa:0 delivers an HTML page with the sentence "protected content". The public web server with the static IPv6 address 2001:db8::bb:0 delivers an HTML page with the sentence "public content".

VII Experimental Validation

We describe the experiment setup and validation experiments for the testbed from Section VI to validate xRAC.

VII-A Experiment Setup

The experiments investigate the communication between the managed host, a particular \acrac, the protected web server, and the public web server. We encapsulate the wget tool [55] as \acrac to retrieve files using HTTP. In our experiments, we use the \acrac to request an HTML file from both the protected and the public web server. We add \acuand, \accand and \accazd on the RADIUS server that allows a particular user to run the \acrac and access the protected web server.

VII-B Validation Experiments

We perform the following experiments as depicted in Figure 12. Before launching the \acrac, we validate with ICMP echo requests from the managed host that the public web server (1a) but not the protected web server (1b) is accessible without authorization. Now, we demonstrate that the integrity of \acprac is verified during authentication, i.e., that a \acrac with a divergent image checksum cannot be started. We create another \acrac image that encapsulates a patched version of wget and try to start it using the user credentials as set up on the RADIUS server. Authentication fails, i.e., the \acrac cannot be started on the managed host. Now, we demonstrate that the correct \acrac can be started and that it can access the protected web server after successful \acaa. After issuing the command to start the \acrac, it is authenticated and authorized as described before (2a). The SDN controller receives \accazd and programs the SDN switch to permit packet forwarding between the \acrac and the protected web server (2c). Now, the \acrac is able to receive the requested HTML file from the protected web server (2d). Trying to load the same HTML file with wget directly from the managed host fails (2e), i.e., the protected web server can be reached by the \acrac but not by the managed host.

VIII Performance Considerations

Container virtualization has no remarkable performance overhead compared to native application execution [56]. xRAC adds delay only to the startup time through the CMD. The CMD requires time to calculate the container’s integrity checksum and to perform AA using network-based 802.1X. Without xRAC, starting the wget container from Section VII-A takes approximately 0.6 s. With xRAC, the startup time is increased to 1.51 s. The wget container image is 6 MB large and the calculation of its SHA256 hash takes 0.12 s on our platform. However, the computation time scales with the image size. For example, a Chrome browser container image with 880 MB takes 3.2 s. The duration of the AA operation depends on the performance of the three 802.1X components and the network in between. The container supplicant is part of the managed host and, therefore, covers only little load. The container authenticator is part of the controller and responsible for many hosts. However, its performance can be scaled up by running multiple instances. The authentication server may be based on RADIUS. This technology is proven to scale well with large deployments and high load by replicating server instances.

IX Conclusion

In this work we proposed xRAC, a concept for execution and access control for restricted application containers (RACs) on managed clients. It includes authentication and authorization (AA) for RACs such that only up-to-date RAC images can be executed by permitted users. Moreover, authorization is extended to protected network resources such that authorized RACs can access them. Traffic control is simplified through the fact that all traffic of a RAC is identified by its IPv6 address. We presented the architecture of xRAC and showed by a prototype implementation that xRAC can be built from standard technologies, protocols, and infrastructure. Our prototype of xRAC leverages Docker as container virtualization platform, signalling is based on 802.1X components. Modifications were needed to the supplicant, the authenticator, and the authentication server so that both user and container AA data can be exchanged. Moreover, the container authenticator is extended to inform required network control elements about authorized RACs. We used the prototype to experimentally validate xRAC and investigate on the performance. After all, we discussed use cases and showed that xRAC supports software-defined network control and improves network security without modifying core parts of applications, hosts, and infrastructure.