---
# System prepended metadata

title: 'Container Security: Issues,Cha'
tags: [paper]

---

## 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抱持疑慮的態度主要還是在資安上

![](https://hackmd.io/_uploads/r11_YSvph.png)

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.


![](https://hackmd.io/_uploads/rJwCv9Opn.png)
