## Container Security: Issues,Challenges,and the road ahead:

四個container security面向:
1. protecting a cotainer from applications inside it
2. inter-container protection
3. protecting host from containers
(1,2,3)software-based protections
5. protect containers from a malicious or semi-honest host(讓container抵禦外部的攻擊):
(5)hardware-based protection

前三個點比較注重在linux kernel features:
>cgroups,namespace,capabliites,seccomp,==AppArmor==(linux secuirt modules)
>AppArmor常用在trusted platform modules(TPM),Intel SGX

1. Introduction:
container startup time 50ms vs vitual machine 30-40 secs

containers因為寄宿在host上，所以安全性跟VM比還是有差

* container security 比較沒有統一的解決方案，各有各的使用場景，像是Intel Software Guard Extensions(SGX)他可以用不信任的host執行

section II : background material,relevant resources
section III: threat model and the proposed use cases
section IV: sofware and hardware solutions to protect containers
section V: 談到與container相關的漏洞
section VI: future research directions and open issues

B. monolithic and microservice archtitecture
host kernel introduces many secuirty issues which make them less secure than VMs

在SOA出現之前，大部分應用程式都是單體(monlithic)
,大部分公司對於container抱持疑慮的態度主要還是在資安上


C. Literature review on container security
> 挑選幾篇真的提到security paper出來放到後面的citation

* threat model:(以container角度，threat從哪裡來)
內部防禦:
1. 保護container,避免application內部攻擊
外部防禦:
1. 避免host攻擊container
2. 來自其他container的攻擊

III. threat model:
* registry,orchestration不是這篇主要探討的，主要探討的是host與container間的關係

1. malicious adversary:
* 使用的方式可以是==摧毀溝通雙方的聯繫==(connection rejection)
* 另一種是在雙方繼續維持聯繫，但不知道已經被駭了
2. semi-honest adversary:
* 收集資訊，而不是透過網路連線癱瘓

Use case1: 1. application入侵自家的container，減少infra 的attack(OS,architecture)

Use case2: 其他被入侵的container影響其他container的運作，還有從其他container竊取資料
* 解決辦法:其他container不知道其他container的存在，還有VM存在

作者實測過這些攻擊手段到Docker,LXC,OpenV上，==spectre,Meltdown==是比較常見的攻擊方式

Use Case 3: protecting the host from containers
* semi-honest container可以獲取host 資料
* 解決辦法： 讓被入侵的container不能access host資料
* malicious container會消耗所有host資源
* 解決辦法：把application設定成service，限制一個service能使用的資源

Use case 4: running applications on untrusted host
>遇到的問題是：
1. *==修改applications profiling==* ,改變application的行為
2. ==unauthorized access for container data==

IV: software and hardware solutions
A. software-based protection mechanisms:
> 1.linux security features
> 2.linux security modules

### software-based mechanisms
a. linux kernel features:
> Inter-container Protection using Namespaces (Use case 2)-->防止其他container竊取現在container資料
> Protecting the Host from Containers using Namespaces(use case 3)-->如果container裡面的process要提權，由於namespce的關係，他不會讓host machine的process受到影響
> 如何做到上面那一點，不讓host machine process受影響，
如果有process想要提權，就幫他建立另一個namspace

那如何對抗資源攻擊呢？ --> 資源不足狀況
* 一開始想法是控制配給namespace的總資源數量，但是事實是這樣的控制模式，其實就跟vm沒什麼兩樣了(coarse grained)

b. 於是有了control groups(cgroups):
跟給一個namespace多少資源最大的不同是，cgroups是讓process這邊都一層資源隔離，每個process看到能使用資源量都不同，讓process知道自己最多能用多少資源，這樣的模式可以防止Dos攻擊
cgroups
* 解決了:
>cpu dos attack(ContainerDrone): 可以防止cpu資源被一個container全部吃掉
* 不能解決：
> memory dos attack,因為這類的攻擊可能來自於host 上的app，沒有被cgroups給規範資源用量，他還是可以無上限的用cpu資源，所以paper是說還是會用到kernel module: ==MemGuard kernel==, 保護memory被一個cpu core吃掉

c. Capablities:(38個capcabilities)
如果一個apache web server他需要開啟本機與container的mapping,需要root權限才可以執行這個行為，不過這樣是非常危險的，所以才會使用linux capabiliteis
> 所以linux這邊才會想說給這樣的行為CAP_NET_BIND_SERVICE的capabilities,without requiring root access
> 假如container本身被hacked了，如果有設定container的capabilites就不用擔心host被container提權變成root

d. seccomp is a linux kernel (比capabilities更fine-grained)
>Split-Phase Execution of Applica-
tion Containers (SPEAKER) 幫助container在啟動過程ˊ中分辨哪些system calls是必要的哪些是不必要的，去做filter-->結果==more than 35% with an unim-
portant performance overhead.==
>> 有人提出在testing phase時，建立出沙盒以攔截container產生的system call(包含透過application產生的system call),但是這樣做的做法會在sandbox profiling還沒設定好之前，container就會產生出一些惡意的system call，paper說先假設這段期間container是ok的

* hard limit:container最多就只能用多少
* soft limit:給container必要的資源即可
**capabilities要使用最小權限原則**,不然跟root越像越不好

>docker目前預設是會block 44 system calls,但是沒辦法為上層的application設計他們只能接受哪些system calls

LSM(linux security modules):
> lsm 提供security modules加入到linux kernel裡面
> LSM提供MAC(mandatory access control) 給kernel
>> LSM負責的主要面向任務：
>> LiCShield 追蹤image執行過程，還有建立profiles給LSM的(Apparmor)
>> LiCShield的缺點是沒有先用弱掃工具去做

* 預設docker images 弱掃是建立在用==SELinux policies==搭配container images,讓SElinux檢測發生問題時，不會影響host還有其他的container runtime

另外一種做法是不讓每個container使用LSM,讓每個container用自己定義的security profiles,建立security namespace,設定routing mechanism,規範哪些container可以互通或是行為．>Their results show that security namespaces protect against several security issues within containers with < 0.7% increased latency.

### B. hardware-based protection mechanisms

==vTPMs,Intel SGX== 可以協助container不被malicious hosts給侵入

1. Virtual Trusted Platform Modules(vTPM)

> 因為cloud 環境的發展，想要選擇另外一套modules,配合VM需求
,hypervisor needs to make TPM available
> vTPM目前是說沒有hardware版TPM來的安全

現在vTPM處理流程：
1. start with secured/measured boot
2. provide a verfied systm platform
3. build the chain of trust in the rooted hardware
4. extend the chaon of trust to the boot loader,OS kernel,system images,container runtime,container images

* 有兩種實作方式:
1. 每個container掛一個vTPM,然後底層再去跟TPM溝通
2. 每個container有一個adapter去跟manager溝通(統一和TPM的角色)-->vTPM manager的負擔就變得比較重

2. Intel SGX(SCONE) Secure Linux Containers with Intel SGX(SCONE):
supports asynchronous system calls and user-level threading.

--> SGX方式可以幫助不只是在os這層保護到container，還有
hypervisor那層也可以做保護

* SGX整合到kubernetes環境中:
難度在於很容易==SGX machines==會在container部署在機器上時，記憶體就會被用光，paper希望能為SGX machine弄個profiling(k8s dashboard?)

### V. other aspects of containers security

1. A. VULNERABILITIES, EXPLOITS, AND TOOLS vulnerabilities management and standard guidelines.

-->目的: 想要在漏洞發生時，知道是哪個危害
penetration testing for specific attacks such as DoS, container escape, and side channels.

需要在捕捉到這樣的alert之後，分析危害與事件種類
> Barlevet al. [97] presented Starlight, a centralized system protection tool which intercepts and analyzes events to determine if the system administrator needs to be alerted.

2. B. ON STANDARDS, EVALUATION METHODOLOGIES,AND RECOMMENDATIONS
> 1. images, focusing on actions to be carried out by the user to assess the security of a container image.
>>presented a comprehensive benchmark that provides guidelines for securing Docker (using Docker CE 17.06 or later) through a step-by-step checklist.