AppArmor Proﬁle Generator as a Cloud Service

Hui Zhu and Christian Gehrmann

Department of Electrical and Information Technology, Lund University, Lund, Sweden

Keywords:

Security-as-a-Service, Docker, Container, AppArmor.

Abstract:

Along with the rapid development of containerization technology, remarkable beneﬁts have been created for

developers and operation teams, and overall software infrastructure. Although lots of effort has been devoted

to enhancing containerization security, containerized environments still have a huge attack surface. This paper

proposes a secure cloud service for generating a Linux security module, AppArmor proﬁles for containerized

services. The proﬁle generator service implements container runtime proﬁling to apply customized AppArmor

policies to protect containerized services without the need to make hard and potentially error-prone manual

policy conﬁgurations. To evaluate the effectiveness of the proﬁle generator service, we enable it on a widely

used containerized web service to generate proﬁles and test them with real-world attacks. We generate an

exploit database with 11 exploits harmful to the tested web service. These exploits are sifted from the 56

exploits of Exploit-db targeting the tested web service’s software. We launch these exploits on the web service

protected by the proﬁle. The results show that the proposed proﬁle generator service improves the test web

service’s overall security a lot compared to using the default Docker security proﬁle.

1 INTRODUCTION

Containerization is by far the most eye-catching tech-

nology as an alternative or companion to virtualiza-

tion. Gartner predicts that by 2022, more than 75%

of global organizations will be running containerized

applications in production

. However, while enjoy-

ing the signiﬁcant beneﬁts brought by containeriza-

tion technology such as portability, efﬁciency, and

agility, several security issues also arise by the kernel-

sharing property of containerization (Casalicchio and

Iannucci, 2020). Containers and microservices ar-

chitectures are different from the traditional virtual

machines with monolithic applications (Martin et al.,

2018). DevSecOps is a set of practices that combines

software development (Dev), security (Sec), and IT

operations (Ops), which means built-in security in

application development through the whole service

life-cycle (Myrbakken and Colomo-Palacios, 2017).

Cloud Security Alliance (CSA) points out that De-

vSecOps are created as a response to resolve security

issues that have risen from microservices-based archi-

tectures

. CSA deﬁnes six focus areas critical to inte-

https://www.gartner.com/smarterwithgartner/6-best-

practices-for-creating-a-container-platform-strategy/

https://cloudsecurityalliance.org/artifacts/six-pillars-

of-devsecops/

grating DevSecOps into an organization, one of which

is automation. The security for microservices in con-

tainers should be automated to protect the environ-

ment and data. Several security controls for contain-

ers have been embedded into a continuous integration

and delivery pipeline to ensure the automated end-to-

end security of containers. One of such controls is

called behavior-based control securing the container

runtime.

Many different behavior-based solutions have ap-

peared in the industry. The top container security

products’ typical way is to monitor the container’s be-

havior and detect malicious activities by using rule-

based or machine-learning-based approaches. For ex-

ample, the TwistLock runtime offers both static anal-

yses and machine-learning-based behavioral monitor-

ing (Stopel et al., 2020). The TwistLock monitoring

and proﬁling defense work on four levels: the ﬁle sys-

tem (Levin et al., 2020a), the processes, the system

calls, and the network (Levin et al., 2020b). Sim-

ilarly, Aqua’s runtime security for Docker restricts

privileges for ﬁles, executables, and OS resources

based on a machine-learned behavioral proﬁle to en-

sure that only necessary privileges are given to the

Zhu, H. and Gehrmann, C.

AppArmor Proﬁle Generator as a Cloud Service.

DOI: 10.5220/0010434100450055

In Proceedings of the 11th International Conference on Cloud Computing and Services Science (CLOSER 2021), pages 45-55

ISBN: 978-989-758-510-4

container

. NeuVector

, StackRox

and Sysdig

also

provide similar products. Besides the container secu-

rity companies, British Telecommunication also has a

patent called software container proﬁling, which can

generate runtime proﬁle for the container in execu-

tion (Daniel and El-Moussa, 2019). Two open-source

projects secure containers based on the runtime be-

havioral monitoring: Falco

and Dagda

. Falco is

a cloud-native runtime security tool that can detect

and alert on any behavior that involves making sys-

tem calls such as running a shell inside a container or

unexpected read of sensitive ﬁles. Dagda adds build-

time analysis on top of Falco’s runtime analysis.

However, not many similar solutions have been

introduced in academic works. Some researchers

propose novel design ideas but lacking implementa-

tion details and experimental results. In the work of

Sarkale et al. (2017), a new security layer with extra

security features on top of the container architecture is

proposed to secure the cloud container environment.

The proposed layer has two features: Container Secu-

rity Proﬁle (CSP) and the Most Privileged Container

(MPC) feature. CSP is responsible for access con-

trol enforcement. It describes the minimum resource

requirements, runtime behavior, and extra privileges

for the container. The MPC is monitoring the system

and detects any attempt to act against assigned per-

missions. The MPC alerts the container engine when

suspicious processes are detected. This in turn allows

the engine to halt a potentially dangerous process.

Most recently, in the work of Zhu and Gehrmann

(2020), a command-line tool called Lic-Sec was pro-

posed which implements Linux tracing tools: System-

Tap

and Auditd

to trace the behavior of the con-

tainer runtime and generate a Linux security module

AppArmor

proﬁle. Docker container security is sig-

niﬁcantly enhanced by restricting the privileges of ca-

pabilities, network accesses, ﬁle accesses, and exe-

cutables based on an automatically generated AppAr-

mor proﬁle. The tool is experimentally evaluated to

be efﬁcient to real-world attacks, especially the privi-

lege escalation attacks. However, the original Lic-Sec

work does not take proﬁle generation dur-

https://blog.aquasec.com/topic/runtime-security

https://neuvector.com/products/container-security/

https://www.stackrox.com/use-cases/threat-detection/

https://sysdig.com/products/kubernetes-

security/runtime-security/

https://github.com/falcosecurity/falco

https://github.com/eliasgranderubio/dagda#monitoring-

running-containers-for-detecting-anomalous-activities

https://sourceware.org/systemtap/

https://linux.die.net/man/8/auditd

https://www.openhub.net/p/apparmor/

ing container usage into account, which may cause

the generated proﬁles to be too restrictive to func-

tion in the ﬁnal container deployment environment.

In this paper, we provide a novel cloud tool for Ap-

pArmor proﬁle generation, which utilizes Lic-Sec but

allows dynamic and automatic AppArmor proﬁle gen-

eration following the DevSecOps automation princi-

ple. Furthermore, we evaluate the proﬁle generator’s

strength by running a typical set of containerized web

services against a ﬁltered set of relevant known ex-

ploits. The evaluation is based on a designed mi-

croservice, and we show the signiﬁcant security im-

provements achieved with our automated cloud-based

proﬁle compared to using the default Docker security

conﬁguration

In summary, we make the following contributions:

• We propose, design, and implement a novel, dy-

namic, AppArmor Proﬁle Generator as a Cloud

Service.

• We evaluate the efﬁciency of the proﬁle genera-

tion service by testing, on widely used container-

ized web services, the generated proﬁle’s strength

against real-world exploits.

The rest of this paper is organized as follows. In

Section 2, we give a background description of Lic-

Sec and the classiﬁcation for containers. In Section

3, we formulate the main research problem, i.e., the

design goal of the proﬁle generator cloud service, and

the evaluation goal of the performance of the gener-

ated proﬁle. In Section 4, we introduce the cloud ser-

vice approach of the proﬁle generator in detail. In

Section 5, we describe the implementation details of

the cloud service. In Section 6, we introduce how the

microservice used in the evaluation is designed and

how the exploit database is generated. In Section 7,

the proﬁle generator cloud service’s primary evalua-

tion results are presented, and a detailed analysis of

the results is given. In Section 8, we present and dis-

cuss related work. In Section 9, we conclude this re-

search and identify future work.

2 BACKGROUND

In this section, we describe Lic-Sec and the classiﬁ-

cation for containers.

2.1 Lic-Sec

Lic-Sec (Zhu and Gehrmann, 2020) is a command-

line tool that can automatically generate AppArmor

proﬁles based on container runtime behaviors. Lic-

Sec combines LiCShield (Mattetti et al., 2015) and

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

Docker-sec (Loukidis-Andreou et al., 2018), both of

which enhance container security by applying cus-

tomized AppArmor policies. Lic-Sec has two primary

mechanisms, including tracing and proﬁle generation.

SystemTap collects all kernel operations while Auditd

collects mount operations, capability operations, and

network operations. This information is processed by

the rules generator engine, and eventually, the AppAr-

mor proﬁle is generated. Rules generated by Lic-Sec

include capabilities rules, network access rules, pivot

root rules, link rules, ﬁle access rules, mount rules,

and execution rules. This tool has been utilized in our

new cloud-based proﬁling solution.

2.2 Container Classiﬁcation

A container can support almost any type of applica-

tion traditionally virtualized or runs natively on a ma-

chine. To design a microservice evaluated by our new

AppArmor proﬁle tool, we have searched and clas-

siﬁed the major container use cases. We explored

the top 50 most popular Docker ofﬁcial images from

Docker hub

in 2020 and classiﬁed them based on

their labels. The ﬁnal classiﬁcation result is displayed

in Table 1. The total amount of images in the ta-

ble is larger than 50 since some images are labeled

with multiple categories. The results clearly show

that containerized database accounts for the largest

proportion, followed by the containerized application

services and infrastructures. Among the category of

containerized application infrastructure, web server

takes 50 percentage. Consequently, containerization

is widely applied to databases and server-side appli-

cations. Other major use cases are containerizing

services, programming languages, and operating sys-

tems.

Table 1: A summary of category for Docker ofﬁcial images.

Category Sub-category Amount Percentage

Database

Database and

Storage System

15 30%

Application

service

Service and Tool 14 28%

Application

infrastructure

Web Server 5 20%

Reverse Proxy 3

Frontend 1

Service discovery 1

Programming

Language

8 16%

Base image Operating System 5 10%

https://hub.docker.com/search?q=&type=image

Figure 1: Scenario Overview.

3 PROBLEM DESCRIPTION

We are considering the scenario in Figure 1 where an

administrator, A, wants to launch an arbitrary service,

S, on a container. The service can be launched on a

local container infrastructure or a third-party cloud in-

frastructure utilized by the administrator. In this sce-

nario, the administrator is responsible for preparing S

and running it on a suitable container platform. To

achieve this goal, the administrator can leverage dif-

ferent protection schemes to enhance the container

platform’s security. One such scheme is based on

AppArmor security architecture, using the Mandatory

Access Control (MAC) to protect the container from

external threats. However, MAC is complicated to

conﬁgure manually even if the administrator has good

knowledge of the microservices since the MAC rules

are directly related to the Linux kernel. Furthermore,

even if the administrator can conﬁgure it, the rules’

scope is still hard to deﬁne since it cannot be too strict

to blocking the microservice’s essential functions nor

too generous to open up for attacks on containers.

Therefore, the aim of this research is, ﬁrst, to pro-

vide a cloud service to generate tailored AppArmor

proﬁles for the administrator in order to protect differ-

ent microservices in the most user-friendly way. Sec-

ond, to evaluate the efﬁciency of the generated pro-

ﬁles in a real production environment. To accomplish

these goals, we want to solve the following two main

problems: 1) ﬁnd a user-friendly cloud service to gen-

erate a tailored AppArmor proﬁle for an arbitrary mi-

croservice automatically; 2) ﬁnd a suitable methodol-

ogy and test framework for evaluating the strengths of

the proﬁles generated by the cloud service.

AppArmor Proﬁle Generator as a Cloud Service

4 CLOUD SERVICE APPROACH

We suggest a solution where a MAC proﬁle genera-

tion is offered as a security service for container ad-

ministrators. The MAC proﬁle generator is based on

Lic-Sec, which has been described in Section 2.1. The

proposed proﬁle generation service ofﬂoads the ad-

ministrator of a container service the burden of set-

ting up a protection proﬁle generation environment.

In particular, the following principles apply (see also

overview Figure 2):

1. An administrator, A, prepares a new service, S, to-

gether with conﬁguration information, C, includ-

ing parameters such as the mounted volumes, the

open ports, the needed capabilities, etc., as well

as a test suite, T, for S. S will be deployed on a

container on local or third-party cloud resources

as a new service with the given conﬁgurations. T

consists of cases for testing all functions of S.

2. A is assumed to have an agreement with a

container security provider and set up a secure

connection (authenticated, conﬁdentiality and in-

tegrity protected) with these providers. The

provider evaluates if the requester has an agree-

ment with the provider. If this is the case, the

provider launches a new Virtual Machine (VM),

including container launch proﬁle and MAC pro-

ﬁle generator on an internal cloud resource. Login

credentials for the VM running container services

are created on the internal resources, and a URL,

as well as credentials for accessing the VM, are

returned to the administrator machine.

3. A uses the credentials received in step 2) to make

a secure connection to the new VM created in the

proﬁle generation service cloud. Using the re-

ceived credentials, A logs in to the VM and up-

loads S, C, and T to the VM.

4. A script on the VM launches container(s) with the

uploaded S and the given C. The functions of S

are tested automatically during the tracing period

by running T. Then, the script generates a MAC

protection proﬁle based on the trace records. T is

rerun with proﬁle enforced to verify no function

of S is blocked by the proﬁle. If the veriﬁcation

fails, the service provider informs A of the failure

and discontinues this service.

5. The proﬁle generated in step 4 that is success-

fully veriﬁed is temporarily stored, and the VM is

killed, and all its data is wiped out from memory.

6. P is returned to A by sending a proﬁle download

link to A.

Figure 2: Proﬁle Generator as a Cloud Service Solution

Overview.

Figure 3: The implementation framework of proﬁle genera-

tor service.

7. A takes the received MAC proﬁle, P, and launches

S on a local or remote container service with the

proﬁle applied.

5 IMPLEMENTATION

The implementation framework is displayed in

Figure 3. Openstack is implemented as the internal

cloud platform of the proﬁle generator service. A

backend server and a data storage with contract users’

information are running on the cloud to provide three

main functions: user authentication, service launch,

and proﬁle fetch. The detailed description for each

function is as follows:

User Authentication: The user is authenticated by

the backend server (username and password). After

successful authentication, the backend server sets up

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

a VM with a ready-to-use proﬁle generation environ-

ment on Openstack. Openstack generates the SSH

key and the ﬂoating IP address for this VM. The back-

end server collects this information from Openstack

and sends it back to the user. The proﬁle genera-

tion environment includes the following pre-installed

components:

• Proﬁle Generator: We use the Lic-Sec tool de-

scribed in Section 2.1 for tracing behaviors and

generating AppArmor proﬁle for the uploaded

service.

• Service Manager: This is a bash script re-

sponsible for discovering newly uploaded service,

launching Docker service, and enabling the proﬁle

generator and veriﬁer, which automates the proﬁle

generation and veriﬁcation.

• Veriﬁer: We use Newman

as the veriﬁer, which

is a command-line collection runner for Post-

man

. It is responsible for running RESTful API

tests in the test suite uploaded by the user. The test

suite is a JSON ﬁle and easy to run with a simple

command: $newman run < testsuite. json >.

• Docker Environment: The Docker CLI, the

Docker daemon, and the docker-compose package

constitute the Docker environment, which runs

the uploaded service in Docker containers.

Service Launch: A user uses the received SSH key

and IP address to build a secure connection with the

VM. To use the proﬁle generation service, the user

needs to prepare the service and conﬁgurations for

running the service in Docker containers and a test

suite script created by the service(s) owner. The script

tests all the service’s functionalities (see also the dis-

cussion on test suit preparation below). For the con-

ﬁgurations, the user can directly use the Docker Com-

pose ﬁle. For the test suite, the user can use the JSON

ﬁle exported from Postman Collection. Once the ser-

vice, conﬁgurations, and test suite are uploaded, the

service manager inside the VM runs the service with

docker-compose and starts the proﬁle generator. Si-

multaneously, the service manager enables the train-

ing period and calls the veriﬁer to run the test suite.

After the training phase is over, and the proﬁle is suc-

cessfully generated, the service manager calls the ver-

iﬁer again with the proﬁle enforced. Hence, the two

signiﬁcant phases of service launch are training and

veriﬁcation. Below, we discuss them in more detail.

• Training: The proﬁle generator uses Lic-Sec to

trace the runtime behavior of the service, which

has been described in Section2.1. At the same

https://www.npmjs.com/package/newman

https://www.postman.com/

time, Newman runs the test suite, and all the func-

tionalities of the service are tested.

• Veriﬁcation: Veriﬁcation ensures that the gener-

ated proﬁle does not block any functionality of

the service. The service manager ﬁrst enforces

the generated proﬁle and then calls Newman to

rerun the test suite. If any test case fails, the ser-

vice manager restarts the proﬁle generation ser-

vice and regenerates the proﬁle. If the veriﬁca-

tion fails three times, the service manager stops

the proﬁle generator and sends an error message

to the backend server. The backend server then

provides a secure link for users to check the failed

cases. The users can ask for technical supports

from the proﬁle generator service provider.

Proﬁle Fetch: Once the veriﬁcation is successful,

the proﬁle generated inside the VM is uploaded

to the backend server immediately by the service

manager. Upon receiving the proﬁle, the backend

server requests Openstack to kill this VM completely.

Meanwhile, the backend server temporarily saves the

proﬁle locally and provides a secure link for users to

download the proﬁle.

Test Suite Preparation: Postman is a popular API

client that has been widely used by developers to cre-

ate and save HTTP/s requests, read and verify their

responses. The Postman Collection is a built-in func-

tion that includes a set of pre-built requests. Newman

automates the running and test of a Postman Collec-

tion. Users create a new collection by merely clicking

+NewCollection in the Postman GUI and then import

all pre-built requests against the same service into this

new collection. To run the collection with Newman,

users should export the collection as a JSON ﬁle. This

ﬁle is the test suite that will be run by the veriﬁer au-

tomatically during the training period. The required

permissions and ﬁle operations by those requests are

traced to generate the proﬁle. If the test suite misses

any request, corresponding permissions, and ﬁle oper-

ations required to handle the request will not be gen-

erated in the proﬁle. Therefore, the proﬁle’s effective-

ness dramatically relies on the test suite’s quality, and

the generated proﬁle only ﬁts the service that has been

trained. It is the users’ responsibility to guarantee that

the test suite covers all functions of the service. We

consider it not an extra effort since an end-to-end test

of a service is typically required before publishing the

service independently of our cloud proﬁle generation

service.

AppArmor Proﬁle Generator as a Cloud Service

6 EXPERIMENTAL SETUP

Here, we describe the experimental set-up used

in our evaluation. First, we discuss the selection

and deployment of the microservice used in our

evaluation. Then we describe how we have collected

and classiﬁed the exploits targeting this microservice,

and ﬁnally, we explain how the tests were executed.

Microservice Selection and Deployment: We de-

cide to use a web service stack to build the evaluated

microservice. This stack compiles software that

enables the creating and running of complex websites

on any computer. It usually includes a web server,

a database system, an underlying operating system,

and supports for particular programming languages.

It is very suitable to be used as the underlying

stack for building the containerized service since

databases, server-side applications, programming

languages, and operating systems are commonly

deployed as microservices in Docker containers as

concluded in Section 2.2. Besides, web services are

the most popular services which have been widely

deployed. Based on this stack, the evaluation’s

microservice includes a backend service, a reverse

proxy service, and a database service, each of which

runs in a separate container. We used a simple

secret management system to test the set-up. The

chosen service provides four APIs and safe persistent

storage for secret owners to save and manage their

secrets. To be more speciﬁc, the four APIs are

POST /path

for creating secret and securely saving

it to the database, DELET E/path

< sec

> and

PUT /path

< sec

> for deleting and updating a

speciﬁc secret with sec

, and GET /path

< sec

for fetching a speciﬁc secret with sec

Exploit Database Collection and Classiﬁcation:

We used the exploit collection and classiﬁcation

method reported by Lin et al. (2018). The authors

ﬁrst generated a universe exploit database by col-

lecting the latest 100 exploits of each category from

Exploit-db

. Then they ﬁltered out the exploits

which may probably fail on the container platform

and used a two-dimensional method for classifying

the ﬁnal set. We generated the ﬁnal exploit dataset

and classiﬁed the exploits based on the method

discussed above but modiﬁed it to suit the study’s

evaluation goal. We implement the method from

Zhu and Gehrmann (2020) to obtain the exploits

which were effective on the evaluated microservice

discussed before. We ﬁrst generated the initial uni-

verse set of exploits by searching out the exploits that

mainly target the microservice’s software. Based on

https://www.exploit-db.com

this set, we ﬁltered out exploits that can be defended

by default Docker security mechanisms by analyzing

the exploit codes and launching the exploits in the

Docker containers with default security conﬁgu-

rations. Eventually, we obtained the ﬁnal exploit

dataset with 11 exploits published after 2016 out of

56 exploits, which were harmful to the containerized

web service. We classiﬁed these exploits using the

targeting object and its impact. The exploit details

and their categories are shown in Table 2.

Test Setup: The microservice was set up on a host

running the Linux distribution Ubuntu 18.04.5 LTS

with kernel version 4.15.0-72-generic. This Linux

version was chosen to guarantee that the host is vul-

nerable to the Linux vulnerabilities in the selected

exploit collection. Docker 19.03.1-ce was used for

the microservice. This version was released on 25th

July 2019 and supported Linux kernel security mech-

anisms, including Capability, Seccomp, and MAC.

We implemented the Redis and MySQL database ser-

vices. While implementing MySQL, we also de-

ployed phpMyAdmin as the administrator. Nginx was

implemented as the reverse proxy. PHP was used for

the backend service.

Table 2: Exploit Database Collection.

Object EDB-ID CVE-ID Category

Redis 48272 N/A

Execute code

Gain information

47195 N/A

Execute code

Gain information

40678 CVE-2016-6663 Gain Privilege

MySQL 40360 CVE-2016-6662

Execute code

Gain Privilege

39867 CVE-2015-4870 DoS

N/A CVE-2012-2122

Bypass

Gain information

PHP

47553

48182

CVE-2019-11043 Execute code

Linux 48052 CVE-2019-18634 Gain Privilege

Docker

engine

N/A CVE-2020-13401

Gain information

DoS

phpMyAdmin 40185 CVE-2016-5734 Execute code

44496 CVE-2018-10188 Execute code

7 EVALUATION

Here we present the evaluation results. We start by

summarizing the overall results, and then we make a

detailed analysis of the successful and failed defenses,

respectively.

7.1 Test Results Overview

The evaluation results are listed in Table 3. The re-

sults indicate that, ﬁrst, among all the rules gener-

ated by the cloud service, the ﬁle access rules play a

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

much more signiﬁcant role in defending exploits than

the other rules. Second, the AppArmor proﬁle-based

container protection scheme is more effective against

attacks with a high level of sophistication, which re-

quires many ﬁle manipulations than the simple at-

tacks, which directly exploit targets’ innate ﬂaws with

limited privileges in the proﬁle. We will explain it

in detail by analyzing the attacking principle of the

exploits, the defending principle of the enforced pro-

ﬁles, and the reasons for the failed defenses in the fol-

lowing subsections. It should be noted that limits ex-

ist for the evaluation: ﬁrst, the test proﬁle is generated

based on the designed microservice discussed in Sec-

tion 6. It gives the least privileges for running the ser-

vice without blocking any functionality of this service

only. Therefore, the exploits defended in this evalu-

ation setup may not be defended anymore in another

setup. Second, the generated proﬁle cannot remedi-

ate the vulnerability but prevent attacks exploiting the

vulnerability.

7.2 Successful Defenses

In total, the generated proﬁle successfully defends

7 out of 11 exploits. Among these defenses, 6

defenses are due to the restriction of permissions to

ﬁle resources, and only 1 defense is due to the lack of

speciﬁc capability.

Redis: Two exploits targeting Redis are proved to

be vulnerable to the tested microservice. These

exploits take advantage of an unauthorized access

vulnerability of Redis version 4.x and 5.x. It uses

the Master-Slave replication to load remote modules

from a Rogue Redis server to a targeted Redis server.

It executes arbitrary commands on the target

Successful launch of the exploit requires to create a

malicious exploit module written by the attacker in

the Redis server’s ’/data’ directory. After loading the

module, the attacker can execute arbitrary commands.

The exploit can be launched with the default security

mechanism since the ﬁle access rules for ’/data’

directory is quite generous with no restrictions.

However, the exploits are successfully defended by

the enforced proﬁle. Since the proﬁle only grants

’read’ permission to ’/data’ directory, no ﬁles can be

created inside this directory.

MySQL: Two exploits ( EDB-ID-40678

and

EDB-ID-40360

) aiming to gain privilege inside

the container are successfully defended by the

https://2018.zeronights.ru/wp-

content/uploads/materials/15-redis-post-exploitation.pdf

https://www.exploit-db.com/exploits/40678

https://www.exploit-db.com/exploits/40360

generated proﬁle. These two privilege escalation

exploits take advantage of two critical vulnerabilities

(CVE-2016-6662

and CVE-2016-6663

) in Oracle

MySQL. The former one is a race condition that

allows local users with certain permissions to gain

privileges. The latter creates arbitrary conﬁgurations

and bypasses certain protection mechanisms to

perform arbitrary code execution with root privileges.

The successful launch of EDB-40678 needs to

create a table named ’exploit table’ in directory

’/tmp/mysql privesc exploit’. Since the proﬁle does

not grant any ’write’ permission to this directory,

the launch of the exploit fails. Similarly, to launch

EDB-40360, the attacker must write to the ﬁle

’poctable.TRG’ in directory ’/var/lib/mysql/demo,’

which also requires ’write’ permission to the direc-

tory and the ﬁle. The proﬁle defends the exploit

since there is no rule giving such permissions to the

directory and the ﬁle.

PHP: There is one attack targeting PHP-fpm exploit-

ing CVE-2019-11043

, which is a bug in PHP-fpm

with speciﬁc conﬁgurations. It allows a malicious

web user to get code execution. We used an open

tool to reproduce the vulnerabilitythis tool

. A web

shell is written in the background of PHP-fpm, and

any command can be executed by appending it to all

PHP scripts. This attack cannot be performed with

the proﬁle in force since the exploit needs ’write’

permission to directory ’/tmp’ to create new ﬁles in

this directory, which is not granted in the proﬁle.

The reason is that the evaluated microservice does

not provide an API for users to upload ﬁles to the

server. Consequently, no permissions are granted to

the directory ’/tmp’.

Docker Engine: A vulnerability, CVE-2020-

13401

, is discovered in Docker Engine before

19.03.11. An attacker inside a container with the

CAP NET RAW capability can craft IPv6 router

advertisements to obtain sensitive information or

cause a denial of service. The enforced proﬁle

perfectly defends this attack since the proﬁle discards

the CAP NET RAW capability.

phpMyAdmin: CVE-2016-5734

is an issue of ph-

pMyAdmin which may allow remote attackers to ex-

ecute arbitrary PHP code via a crafted string. The

attack is written in Python and uses the function ’sys-

tem()’ to execute command after exploiting. This

https://nvd.nist.gov/vuln/detail/CVE-2016-6662

https://nvd.nist.gov/vuln/detail/CVE-2016-6663

https://nvd.nist.gov/vuln/detail/CVE-2019-11043

https://github.com/neex/phuip-fpizdam

https://nvd.nist.gov/vuln/detail/CVE-2020-13401

https://nvd.nist.gov/vuln/detail/CVE-2016-5734

AppArmor Proﬁle Generator as a Cloud Service

function’s call needs the execution permission of

’/bin/dash’ to prompt a terminal. The enforced pro-

ﬁle successfully defends this attack since it denies the

execution of ’/bin/dash.’

7.3 Failed Defenses

In total, the generated proﬁle fails to defend 4 out

of 11 exploits. The attacks we could not prevent are

generally not very complicated and do not rely on

any speciﬁc capability or network access.

MySQL: Two exploits are targetting on MySQL

that cannot be defended by the proﬁle. One is a

DoS attack exploiting vulnerability CVE-2015-

4870

to crash the MySQL server by passing a

subquery to function PROCEDURE ANALYSE().

The attack does not require any extra capability

to launch. The required network access is only

’network inet stream’, which is also necessary for

running the MySQL database. Regarding the ﬁle

accesses, the attack needs ’read’ permission to

the directory ’/var/lib/mysql/mysql’, which has been

granted by the proﬁle as it is needed to run the service.

The other uses vulnerability CVE-2012-2122

to log in to a MySQL server without knowing the

correct password. The vulnerability comes from the

incorrect handling of the return value of the memcmp

function, which is an innate ﬂaw of the software.

Hence, the AppArmor proﬁle will not help here. The

ﬁrst attack’s impact is more severe than the second

one since it completely disrupts the database service.

For the second attack, even if the attacker bypasses

authentication and logs in as an authenticated user,

his behavior is still restricted by the enforced proﬁle.

Linux: CVE-2019-18634

is a bug in Sudo before

1.8.26. Pwfeed-back option is used to provide visual

feedback while inputting passwords with sudo. The

option is disabled by default, but in some systems,

users can trigger a stack-based buffer overﬂow in the

privileged sudo process if this option is enabled. The

stack overﬂow may allow unprivileged users to esca-

late to the root account

. The enforced proﬁle fails

to defend this attack since overﬂowing the buffer does

not require extra ﬁle manipulation or extra capabil-

ities. However, the attack’s impact is limited since

the attacker gets root privilege only inside the com-

promised container. The proﬁle is still effective to the

container so that the attacker is still under supervision.

https://nvd.nist.gov/vuln/detail/CVE-2015-4870

https://nvd.nist.gov/vuln/detail/CVE-2012-2122

https://nvd.nist.gov/vuln/detail/CVE-2019-18634

https://www.sudo.ws/alerts/pwfeedback.html

phpMyAdmin: CVE-2018-10188

is a Cross-Site

Request Forgery issue in phpMyAdmin 4.8.0, which

allows an attacker to execute arbitrary SQL state-

ments. The vulnerability comes from the failure in

’sql.php’ script to properly verify the source of an

HTTP request, which is also an innate ﬂaw of the soft-

ware. Similarly, the proﬁle privileges are enough to

launch the attack, which leads to the failed defense.

The impact is relatively high since ’write’ and ’read’

permissions generally should be granted to ensure the

regular operation of a database’s essential functions;

the attacker is unfortunately still able to drop, read or

modify an existing database even if the proﬁle is en-

forced.

Table 3: Evaluation Result Overview.

Categories

Software

Redis MySQL PHP Linux

Docker

Engine

phpMyAdmin

Bypass

(Doc/Svc

)

\ 1/1 \ \ \ \

Gain Privilege

(Inside Container)

(Doc/Svc

)

\ 2/0 \ 1/1 \ \

DoS

(Doc/Svc

)

\ 1/1 \ \ 1/0 \

Gain

Information

(Doc/Svc

)

2/0 1/1 \ \ 1/0 \

Execute Code

(Doc/Svc

)

2/0 1/0 1/0 \ \ 2/1

1: ”Doc” denotes the number of exploits execute successfully on containers launched

with Docker, and ”Svc” denotes the number of exploits execute successfully on containers

launched with the proﬁle generator service.

8 RELATED WORK

There are some researches addressing proﬁling to en-

hance runtime security for containerization environ-

ment. In the work of Pothula et al. (2019), a secu-

rity control map, including rate limit, memory limit,

and session limit, as well as a malware detection sys-

tem with proﬁling, is proposed to harden the security

of runtime containers. All of the limit thresholds in

this control map are derived from lab experiments and

customer use case scenarios. The malware detection

system is responsible for detecting malware behavior

events, conveying semantic information about mali-

cious behaviors, and predicting malware intentions.

Based on the intentions, corresponding security poli-

cies are created automatically. The proposed control

map is experimentally evaluated to improve container

security signiﬁcantly, especially when the attacker is

inside the container. The main difference compared

to our work is that this security control map is proﬁl-

ing the malware behavior but not the container run-

time behavior. Hence, the created security policies

will only protect the container from malware attacks

that have been detected by the malware detection sys-

https://nvd.nist.gov/vuln/detail/CVE-2018-10188

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

tem and no other attacks.

Many commercial products are providing con-

tainer runtime proﬁling, as mentioned in Section 1.

In the academic area, LiCShield (Mattetti et al., 2015)

and Docker-sec (Loukidis-Andreou et al., 2018) men-

tioned in Section 2.1 are two such solutions. Both aim

to secure Docker containers through their whole life-

cycle by automatically generating AppArmor proﬁles

based on container runtime behavior proﬁling. The

main difference is that Docker-sec uses Auditd as the

tracing tool and generates capability rules and net-

work access rules, while LiCShield uses SystemTap

and generates rules other than the ones generated by

Docker-sec such as ﬁle access rules and mount rules.

However, both are command-line tools to be used lo-

cally and do not provide full dynamic proﬁling with

veriﬁcation for the target application.

Other than solutions based on proﬁling, re-

searchers are exploring other ways to enhance con-

tainer security. One direction is to apply customized

LSM modules. Bacis et al. propose a solution that

binds SELinux policies with Docker container im-

ages by adding SELinux policy module to the Docker-

ﬁle. In this way, containerized processes are protected

by pre-deﬁned SELinux policies (Bacis et al., 2015).

This approach requires the system administrator to

have good knowledge of the service running inside

the containers to deﬁne the most suitable SELinux

policy. Consequently, it is not an automatic pro-

cess according to the DevSecOps methodology. Sun

et al. (2018) propose the design of security names-

pace, which is a kernel abstraction that enables con-

tainers to utilize virtualization of the whole Linux ker-

nel security framework to achieve autonomous per-

container security control rather than relying on the

system administrator to enforce the security control

from the host. The experimental results show that se-

curity Namespaces can solve several container secu-

rity problems with an acceptable performance over-

head. An architecture called DIVE (Docker Integrity

Veriﬁcation Engine) is proposed by De Benedictis and

Lioy (2019) to support integrity veriﬁcation and re-

mote attestation of Docker containers. DIVE relies

on a modiﬁed version of IMA (Integrity Measure-

ment Architecture) (Sailer et al., 2004), and OpenAt-

testation, a well-known tool for attestation of cloud

services. DIVE can detect any speciﬁc compromised

container or hosting system and request to rebuild this

single container and report to the manager.

Another direction is to protect containers from

the kernel layer by providing a secure framework

or wrapper to run Docker containers. Charliecloud,

which is a security framework based on the Linux user

and mount namespaces, is proposed by Priedhorsky

and Randles (2017) to run industry-standard Docker

containers without privileged operations. Char-

liecloud can defend against most security risks such

as bypass of ﬁle and directory permissions and ch-

root escape. A secure wrapper called Socker is de-

scribed by Azab (2017) for running Docker containers

on Slurm and other similar queuing systems. Socker

bounds the resource usage of any container by the

number of resources assigned by Slurm to avoid re-

source hijacking. Furthermore, Socker enforces the

submitting user instead of the root user to execute on

containers to avoid privileged operations.

Besides proposing general security solutions for

containers, many pieces of research focus on propos-

ing container security countermeasure or algorithm

against a particular attack category, which includes

special investigations on some common attacks such

as DoS attacks (Chelladhurai et al., 2016), the appli-

cation level attacks (Hunger et al., 2018) and covert

channels attacks (Luo et al., 2016), as well as some

attacks with severe impacts such as container escape

attacks (Jian and Chen, 2017) and attacks from the un-

derlying compromised higher-privileged system soft-

ware such as the OS kernel and the hypervisor (Ar-

nautov et al., 2016). In the work of Chelladhurai et al.

(2016), a three-tier protection mechanism is applied

to defend against DoS attacks. The mechanism is de-

signed with memory limit assignment, memory reser-

vation assignment, and default memory value setting

to limit the container’s resource consumption. Re-

garding the application-level attacks, Hunger et al.

(2018) propose DATS, a system to run web container-

ized applications that require data-access heavy in

shared folders. The system enforces non-interference

across containers of data accessing and can mitigate

data-disclosure vulnerabilities. Covert channel at-

tacks against Docker containers are analyzed by Luo

et al. (2016). They identify different types of covert

channel attacks in Docker and propose solutions to

prevent them by conﬁguring Docker security mech-

anisms. They also emphasize that deploying a full-

ﬂedged SELinux or AppArmor security policy is es-

sential to protect containers’ security perimeters. Jian

and Chen (2017) make a thorough investigation of

Docker escape attacks and discover that a successful

escape would create different Namespaces. There-

fore, they propose a defense based on Namespaces

status inspection, and once a different Namespaces

tag is detected, the afﬁliated process is killed imme-

diately, and the malicious user is tracked. The test

results show that this defense can effectively prevent

some real-world attacks. SCONE is proposed by Ar-

nautov et al. (2016), which is a secure container en-

vironment for Docker utilizing Intel Software Guard

AppArmor Proﬁle Generator as a Cloud Service

eXtension (SGX) (Hoekstra et al., 2013) for running

Linux applications in secure containers.

Some researches aim to provide secure connec-

tions for Docker containers. In the work of Kelbert

et al. (2017) and Ranjbar et al. (2017), both of them

propose solutions to build secure and persistent con-

nectivities between containers. The work of Secure

Cloud proposed by Kelbert et al. (2017) is realized

with the support of Intel’s SGX. While the SynAP-

TIC architecture from Ranjbar et al. (2017) is based

on the standard host identity protocol (HIP). Cilium

is open-source software for securing the network con-

nectivity between containerized application services.

9 CONCLUSION AND FUTURE

WORK

In this paper, we have proposed a secure cloud service

to generate runtime AppArmor proﬁles for Docker

containers. The cloud service is user-friendly and of-

ﬂoads the administrator of a container service the bur-

den of setting up a protection proﬁle generation envi-

ronment. We evaluated the approach by running a set

of typical microservices on the cloud proﬁle genera-

tor solution. We manually collected 11 most relevant

real-world exploits from Exploit-db, which target the

selected microservice’s software. Even if the num-

ber of exploits is not very large, it still gives us a

good view of our approach’s efﬁciency compared to

the strength of the default Docker proﬁle. The results

show that the proﬁle successfully defends 7 out of 11

exploits not covered by the default proﬁle, a consider-

able improvement based on the evaluation set-up. By

analyzing the defending principles, we found that the

proﬁle is more efﬁcient against complicated exploits

that require many ﬁle manipulations. The results also

indicate that among all kinds of rules generated in the

proﬁle, the ﬁle access rules play a much more signiﬁ-

cant role in defending exploits than other rules.

It is left to future work to compare our proﬁle gen-

erator cloud service with other commercial products

mentioned in Section 1 to get a comprehensive un-

derstanding of the proposed service’s strengths and

weaknesses.

ACKNOWLEDGEMENTS

Work supported by framework grant RIT17-0032

from the Swedish Foundation for Strategic Research

https://github.com/cilium/cilium

as well as the EU H2020 project CloudiFacturing un-

der grant 768892.

REFERENCES

Arnautov, S., Trach, B., Gregor, F., Knauth, T., Martin, A.,

Priebe, C., Lind, J., Muthukumaran, D., O’Keeffe, D.,

Stillwell, M. L., et al. (2016). {SCONE}: Secure

linux containers with intel {SGX}. In 12th {USENIX}

Symposium on Operating Systems Design and Imple-

mentation ({OSDI} 16), pages 689–703.

Azab, A. (2017). Enabling docker containers for high-

performance and many-task computing. In 2017 ieee

international conference on cloud engineering (ic2e),

pages 279–285. IEEE.

Bacis, E., Mutti, S., Capelli, S., and Paraboschi, S. (2015).

Dockerpolicymodules: mandatory access control for

docker containers. In 2015 IEEE Conference on Com-

munications and Network Security (CNS), pages 749–

750. IEEE.

Casalicchio, E. and Iannucci, S. (2020). The state-of-the-art

in container technologies: Application, orchestration

and security. Concurrency and Computation: Practice

and Experience, page e5668.

Chelladhurai, J., Chelliah, P. R., and Kumar, S. A. (2016).

Securing docker containers from denial of service

(dos) attacks. In 2016 IEEE International Conference

on Services Computing (SCC), pages 856–859. IEEE.

Daniel, J. and El-Moussa, F. (2019). Software container

proﬁling. US Patent App. 16/300,169.

De Benedictis, M. and Lioy, A. (2019). Integrity veriﬁ-

cation of docker containers for a lightweight cloud

environment. Future Generation Computer Systems,

97:236–246.

Hoekstra, M., Lal, R., Pappachan, P., Phegade, V., and

Del Cuvillo, J. (2013). Using innovative instructions

to create trustworthy software solutions. HASP@

ISCA, 11(10.1145):2487726–2488370.

Hunger, C., Vilanova, L., Papamanthou, C., Etsion, Y., and

Tiwari, M. (2018). Dats-data containers for web appli-

cations. In Proceedings of the Twenty-Third Interna-

tional Conference on Architectural Support for Pro-

gramming Languages and Operating Systems, pages

722–736.

Jian, Z. and Chen, L. (2017). A defense method against

docker escape attack. In Proceedings of the 2017

International Conference on Cryptography, Security

and Privacy, pages 142–146. ACM.

Kelbert, F., Gregor, F., Pires, R., K

opsell, S., Pasin, M.,

Havet, A., Schiavoni, V., Felber, P., Fetzer, C., and

Pietzuch, P. (2017). Securecloud: Secure big data pro-

cessing in untrusted clouds. In Design, Automation

& Test in Europe Conference & Exhibition (DATE),

2017, pages 282–285. IEEE.

Levin, L., Stopel, D., and Yanay, E. (2020a). Filesystem ac-

tion proﬁling of containers and security enforcement.

US Patent 10,664,590.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

Levin, L., Stopel, D., and Yanay, E. (2020b). Networking-

based proﬁling of containers and security enforce-

ment. US Patent 10,599,833.

Lin, X., Lei, L., Wang, Y., Jing, J., Sun, K., and Zhou, Q.

(2018). A measurement study on linux container secu-

rity: Attacks and countermeasures. In Proceedings of

the 34th Annual Computer Security Applications Con-

ference, pages 418–429. ACM.

Loukidis-Andreou, F., Giannakopoulos, I., Doka, K., and

Koziris, N. (2018). Docker-sec: A fully auto-

mated container security enhancement mechanism. In

2018 IEEE 38th International Conference on Dis-

tributed Computing Systems (ICDCS), pages 1561–

1564. IEEE.

Luo, Y., Luo, W., Sun, X., Shen, Q., Ruan, A., and

Wu, Z. (2016). Whispers between the containers:

High-capacity covert channel attacks in docker. In

2016 IEEE Trustcom/BigDataSE/ISPA, pages 630–

637. IEEE.

Martin, A., Raponi, S., Combe, T., and Di Pietro, R. (2018).

Docker ecosystem–vulnerability analysis. Computer

Communications, 122:30–43.

Mattetti, M., Shulman-Peleg, A., Allouche, Y., Corradi, A.,

Dolev, S., and Foschini, L. (2015). Securing the in-

frastructure and the workloads of linux containers. In

2015 IEEE Conference on Communications and Net-

work Security (CNS), pages 559–567. IEEE.

Myrbakken, H. and Colomo-Palacios, R. (2017). Devsec-

ops: a multivocal literature review. In International

Conference on Software Process Improvement and

Capability Determination, pages 17–29. Springer.

Pothula, D. R., Kumar, K. M., and Kumar, S. (2019).

Run time container security hardening using a pro-

posed model of security control map. In 2019 Global

Conference for Advancement in Technology (GCAT),

pages 1–6. IEEE.

Priedhorsky, R. and Randles, T. (2017). Charliecloud: Un-

privileged containers for user-deﬁned software stacks

in hpc. In Proceedings of the International Confer-

ence for High Performance Computing, Networking,

Storage and Analysis, pages 1–10.

Ranjbar, A., Komu, M., Salmela, P., and Aura, T. (2017).

Synaptic: Secure and persistent connectivity for con-

tainers. In 2017 17th IEEE/ACM International Sym-

posium on Cluster, Cloud and Grid Computing (CC-

GRID), pages 262–267. IEEE.

Sailer, R., Zhang, X., Jaeger, T., and Van Doorn, L. (2004).

Design and implementation of a tcg-based integrity

measurement architecture. In USENIX Security sym-

posium, volume 13, pages 223–238.

Sarkale, V. V., Rad, P., and Lee, W. (2017). Secure cloud

container: Runtime behavior monitoring using most

privileged container (mpc). In 2017 IEEE 4th Interna-

tional Conference on Cyber Security and Cloud Com-

puting (CSCloud), pages 351–356. IEEE.

Stopel, D., Levin, L., and Yankovich, L. (2020). Proﬁling

of container images and enforcing security policies re-

spective thereof. US Patent 10,586,042.

Sun, Y., Safford, D., Zohar, M., Pendarakis, D., Gu, Z., and

Jaeger, T. (2018). Security namespace: making linux

security frameworks available to containers. In 27th

{USENIX} Security Symposium ({USENIX} Security

18), pages 1423–1439.

Zhu, H. and Gehrmann, C. (2020). Lic-sec: an enhanced

apparmor docker security proﬁle generator. preprint

on webpage at https://arxiv.org/abs/2009.11572.

AppArmor Proﬁle Generator as a Cloud Service