Container Basics

Chúng ta sẽ đi qua một số khái niệm cơ bản và cần thiết trong docker:

Credentials

Credentials describe the user identity of a task, which determine its permission for shared resources such as files, semaphores, and shared memory.

Capabilities

Since kernel 2.2, Linux divides the privileges associated with superuser into distinct unit known as capabilities

1

/proc/$PID/status | man capabilities

Filesystem

The container’s root mount is often planted in a container-specialized filesystem, such as OverlayFS

1

/var/lib/docker/overlay2/..hash../diff

Namespaces

• Mục đích: làm cho hệ thống container có thể sử dụng và an toàn.
• PID: have their own view of tasks - cung cấp cây không gian tên của process id. Nó cho phép mỗi container có một cây đầy đủ các process id riêng biệt, trong đó init process có pid = 1. Process chạy trên host sẽ có pid khác với khi chạy trên container.
• User: wrap mapping of UID to user - cung cấp phiên bản namespace của User IDs (UIDs) and Group IDs (GIDs). Đây là một trong những tính năng quan trọng nhất của hệ thống container hiện đại vì nó được sử dụng để cung cấp “unprivileged containers”. User namespaces cung cấp một trong những nền tản cho hệ thống container trên Linux hiện nay, và là vùng cấu hình duy nhất được LXC coi là an toàn.
• Mount: isolate mount points - cung cấp chế độ xem không gian tên của các điểm kết nối (mount points). Kết hợp với pivot_root syscall, tính năng này sẽ cô lập container’s filesystem với host’s filesystem.
• Network: cung cấp không gian tên và ngăn xếp mạng riêng biệt. Hầu hết các trường hợp sử dụng của container liên quan tới dịch vụ mạng, vì vậy nó được coi là tính năng lõi của container.
• UTS: have their own hostname - cung cấp namespaced version của định danh hệ thống (system identifies)
• IPC: restrict SysV IPC objects
• Cgroup: isolate the view of cgroups

1

/proc/$PID/ns/

Cgroups

CGroups: cung cấp giao diện phân cấp để quản lí cũng như đo lường tài nguyên và quyền truy cập của thiết bị. Cgroups có thể được sử dụng bởi các process có quyền hạn cao (higher privileged) để đặt giới hạn về sử dụng bộ nhớ, CPU, chặn các thiết bị IO khác. Chúng còn có thể được sử dụng chung với iptables để cung cấp định hình lưu lượng. Quan trong nhất, chúng được sử dụng trong hệ thống container đẻ kiểm soát quyền truy cập của các thiết bị.

Linux Security Modules - LSMs

• AppArmor and SELinux are Linux security modules providing Mandatory Access Control (MAC), where access rules for a program are described by a profile.
• AppArmor là LSM phổ biến nhất trong hệ thống container, nó có thể giới hạn các hành động mà một chương trình nhất định có thể thực hiện, cũng như thực hiện các hành động phức tạp khi bắt đầu process. Cả LXC và Docker đều thiết lập ở chế độ mặc định để xây dựng những rào cản an ninh, chống lại những mối đe dọa theo chiều sâu. Cho đến nay, AppArmor được ghi nhận là hỗ trợ và ghi nhận tốt nhất.
  Do sự đơn giản của cú pháp AppArmor, nó cũng dễ sử dụng hơn rất nhiều để cấu hình tùy chỉnh cho mỗi vùng chứa.
• Docker and LXC enable a default LSM profile in enforcement mode, wh mostly serves to restrict a container’s
  access to sensitive /proc and /sys entries.
• The profile also denies mount syscall.

Tầm quan trọng của Apparmor

Mount Options

• Chính sách của AppArmor chặn việc truy cập để mounting devpts filesystems. Như comment ở dưới, nếu không có chính sách này, container có thể remount /dev/pts và chiếm quyền truy cập vào các thiết bị đầu cuối của máy chủ.

1
2
3
4

# the container may never be allowed to mount devpts. If it does, it
# will remount the host's devpts. We could allow it to do it with
# the newinstance option (but, right now, we don't).
deny mount fstype=devpts

• Các chính sách dùng để chặn container cố gắng remount root filesystem. Chính sách này được thực hiện như một biện pháp phòng thủ theo chiều sâu.

1
2
3

 # ignore DENIED message on / remount
    deny mount options=(ro, remount) -> /,
    deny mount options=(ro, remount, silent) -> /,

Utility Changes

• Có rất nhiều “nơi nguy hiểm” trong /proc và /sys cho phép các container thoát ra ngoài (container escapes).
  Tất cả những điều này liên quan tới việc thay đổi vị trí của một tiện ích (chẳng hạn như modprobe) mà máy chủ sẽ gọi khi một sự kiện nhất định xảy ra (ví dụ như yêu cầu load yêu cầu của kernel module).
  Bằng cách thay đổi điều này để trỏ đến một chương trình bên trong container của chúng ta, attacker sau đó có thể khiến máy chủ chạy một đoạn mã tùy ý bên ngoài container

• LXC sử dụng bộ quy tắc sau để chặn các cuộc tấn công này. Lưu ý, nó không phải là một cấu hình cảu AppArmor, nó là đầu vào cho một đoạn lệnh python nhỏ tạo ra một phần dài (long portion) của các quy tắc AppArmor.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Run lxc-generate-aa-rules.py on this file after any modification, to generate
# the container-rules file which is appended to container-base.in to create the
# final abstractions/container-base.
block /sys
allow /sys/fs/cgroup/**
allow /sys/devices/virtual/net/**
allow /sys/class/net/**
block /proc/sys
allow /proc/sys/kernel/shm*
allow /proc/sys/kernel/sem*
allow /proc/sys/kernel/msg*
allow /proc/sys/kernel/hostname
allow /proc/sys/kernel/domainname
allow /proc/sys/net/**

Những vector quan trọng nào đang bị chặn?

• uevent_helper: uevents là những sự kiện được kernel kích hoạt khi một thiết bị thêm vào hoặc xóa đi. Điều đáng chú ý là đường dẫn của “uevent_helper” có thể được chỉnh sửa bằng cách ghi vào "/sys/kernel/uevent_helper".
  Do đó, khi một uevent được kích hoạt (cũng có thể được thực hiện từ userland bằng cách ghi vào các tệp như "/sys/class/mem/null/event"), “uevent_helper độc hại” sẽ được thực thi.

• modprobe: modprobe là một tiện ích thuộc userland, được kernel gọi khi kernel cần load một kernel module. Vị trí của nó có thể được thay đổi bằng cách sửa đổi "/proc/sys/kernel/modprobe",
  và sau đó chúng ta chỉ cần thực hiện một hành động nào đó để kernel tải một kernel module, code chúng ta sẽ được thực thi. (Chẳng hạn như sử dụng crypto-API để tải crypto-module hoặc sử dụng ifconfig để tải networking module cho thiết bị hiện không sử dụng.)

• core_pattern: core_patterns thường sử dụng để cho kernel biết cách đặt tên và định dạng các core dumps được tạo khi chương trình bị crash.
  Tuy nhiên, nó lại có 1 tính năng rất tệ: “từ Linux kernel 2.6.19. Linux hỗ trợ cú pháp thay thế cho tệp /proc/sys/kernel/core_patterm. Nếu ký tự đầu tiên của tệp này là kí tự pipe (|),
  thì phần còn lại của dòng này được hiểu là một chương trình sẽ được thực thi. Thay vì được ghi vào đĩa, core dump lúc bây giờ sẽ được xem là một chuẩn input của chương trình trên.”.
  Sử dụng tính năng trên, core_pattern có thể được chỉ định để gọi chương trình của chúng ta, rồi để kích hoạt nó, ta chỉ cần làm cho chương trình bị crash.

• /proc/sys/vm/panic_on_oom: đây là global flag, xác định kernel có “hoảng sợ” (panic) khi gặp phải tình trạng hết bộ nhớ hay không (Out Of Memory - OOM). Điều này cho phép chúng ta tiến hành một cuộc tấn công DOS đơn giản.

Dangerous Paths

1
2
3
4
5

  # block some other dangerous paths
  deny @{PROC}/kcore rwklx,
  deny @{PROC}/kmem rwklx,
  deny @{PROC}/mem rwklx,
  deny @{PROC}/sysrq-trigger rwklx,

• kcore cung cấp kết xuất đầy đủ của bộ nhớ vậy lí hệ thống (full dump of the physical memory) ở dạng core file. Nó không cho phép ghi vào bộ nhớ đã nói.
  Quyền truy vào điều này cho phép container có thể đọc tất cả host memory.

• kmem: “/proc/kmem” là một giao diện thay thế cho “/dev/kmem” (quyền truy cập trực tiếp bị chặn bới cgroup device whitelist), là một kí tự đại diện cho kernel virtual memory.
  Nó cho phép cả đọc và viết, cho phép trực tieps sửa đổi kernel memory. (Nó đòi hỏi sự khéo léo hơn một chút so với kmem, vì các địa chỉ ảo cần được phân giải thành các địa chỉ vật lí trước).

• sysrq-trigger: ghi vào tệp đặc biệt này cho phép gửi các lệnh khóa yêu cầu (Request Key commands), cho phép môt số hành động đặc quyền,
  chẳng hạn như hủy các quy trình, liệt kê tất cả các quy trình trên hệ thông hoặc kích hoạt khởi động lại máy chủ.

Các khối quan trọng cuối cùng ghi đến một số nơi khác nhau có thể nguy hiểm:

1
2
3
4
5
6

# deny writes in /sys except for /sys/fs/cgroup, also allow
# fusectl, securityfs and debugfs to be mounted there (read-only)
deny mount fstype=debugfs -> /var/lib/ureadahead/debugfs/,
deny /sys/firmware/efi/efivars/** rwklx,
deny /sys/kernel/security/** rwklx,
deny @{PROC}/sys/fs/** wklx,

• debugfs: cung cấp một giao diện “no rules” mà kernel (hoặc kernel module) có thể tạo ra các giao diện debug có thể truy cập vào vùng người dùng (userland).
  Nó đã có một số vấn đề về bảo mật trong quá khứ và các nguyên tắc “no rules” đằng sau hệ thống tệp thường xung đột với các ràng buộc bảo mật.
  Bên trong một LXC container, nó được gán ở chế độ chỉ đọc.

• /sys/firmware/efi/efivars: efivars cung cấp một giao diện để viết vào NVRAM sử dụng cho các đối số khởi động UEFI (UEFI boot arguments).
  Việc sửa đổi chúng có thể khiến máy chủ không thể khởi động được (unbootable).

• /sys/kernel/security: được gán ở đây là một giao diện securityfs, cho phép cấu hình Linux Security Modules. Nó cho phép cấu hình chính sách của AppArmor,
  vì vậy, quyền truy cập vào điều này có thể cho phép một vùng chứa vô hiệu hóa hệ thống MAC của nó.

• /proc/sys/fs: Thư mục này chứa một mảng các options và thông tin liên quan đến các khía cạnh khác nhau của hệ thống tệp, bao gồm: quota, file handle, inode,
  and dentry information. Ghi vào thư mục này cho phép các cuộc tấn công từ chối dịch vụ khác nhau chống lại máy chủ.

seccomp

• Là cơ chế cho system call filtering. Chính sách của policies đến từ 2 version.
  • Trong version 1, một filter là một tập hợp nhỏ các lệnh gọi hệ thống không thể tùy chỉnh.
  • Trong version 2, “Filter mode”, system call filter được viết như chương trình lọc gói Berkeley (Berkeley Packet Filter - BPF). Điêu
    Đây được gọi là “Strict” mode.
  • LXC hiện tại sử dụng một chính sách khá đơn giản, trong khi bản release 1.10 của docker được giới thiệu hỗ trợ cho seccomp-bpf.
    Một điều lưu ý là trong Docker 1.10, seccomp không được sử dụng theo mặc định trên trusty (hơi khó hiểu vì docker 1.10 trên ubuntu 15.10, seccomp vẫn được sử dụng mặc định).
    Tuy nhiên, kể từ Docker 1.11.1 seccomp hiện cũng được sử dụng theo mặc định trên trusty.

Tầm quan trọng của Seccomp

Seccomp-BPF cho phép cấu hình lọc những “lời gọi hệ thống nguy hiểm”. Đối với một số phiên bản hiện nay, LXC đã xuất xưởng với chính sách seccomp rất nhỏ, đơn giản,
với minh họa ở dưới. Với bản Docker 1.10, Docker đã thêm nhiều chính sách phức tạp hơn.

1
2
3
4
5
6
7
8
9

2
blacklist
reject_force_umount # comment this to allow umount -f; not recommended
[all]
kexec_load errno 1
open_by_handle_at errno 1
init_module errno 1
finit_module errno 1
delete_module errno 1

Phần đầu của chính sách LXC được sử dụng như một biện pháp bảo vệ chuyên sâu để ngăn chạn các vùng chứa buộc phải ummounting các phần của filesystem.

Kernel Manipulation

Một số lệnh cho phép thao tác với kernel module bị cấm (init_module, finit_module, delete_module), cũng như kexec_load cho phép thay thế kernel hiện tại bằng
một kernel images mới. Lưu ý, có một số biện pháp bảo vệ chuyên sâu chống lại việc khai thác chúng trong các container đặc quyền:

• init_module, finit_module, delete_module: tất cả yêu cầu SYS_MODULE capability - đã bị loại bỏ bởi Docker và LXC trong privileged containers.
• kexec_load không yêu cầu SYS_MODULE, thay vào đó nó yêu cầu SYS_BOOT - privileged LXC container giữ. Trong hầu hết các trường hợp, điều này không thể khai thác (mà không bypass seccomp),
  tuy nhiên, điều đáng chú ý là Linux 3.17 đã gới hiệu 1 biến thể mới của kexec: kexec_file_load. Lệnh gọi này (tải signed kernels) không nằm trong danh sách đen của privileged LXC container, và chỉ yêu cầu SYS_BOOT. Tuy nhiên, vùng chứa LXC đặc quyền có một số vấn đề khác cho phép thoát khỏi container mà không cần boot vào kernel mới (vì trên thực tế, chúng ta có thể bypass seccomp).

The Issue With open_by_handle_at()

open_by_handle_at là một lợi gọi hệ thống khá thú vị, ban đầu nó được đưa vào kernel để hỗ trợ userspace file servers để các process dễ dàng chuyển các mã định danh tệp duy nhất (unique file identifiers) cho nhau.
Tuy nhiên, nó lại là một cơn ác mộng của bảo mật. Bất kì process nào có khả năng DAC_READ_SEARCH đều có thể sử dụng open_by_handle_at để có quyền truy cập vào bất cứ tệp nào,
ngay cả các tệp bên ngoại không gian tên gắn kết của chúng. Xử lí được chuyển vào open_by_handle_at nhằm mục đích giúp một số nhận dạng không rõ được truy xuất bằng cách sử dụng name_to_handle_at.
Tuy nhiên, quá trình xử lí này lại chứa thông tin nhạy cảm và có thể bị giả mạo. Lỗi này được chỉ ra trong docker container bởi Sebastian krahmer, điều này đã ảnh hướng đến cả LXC và Docker.
Nó cũng là một vấn đề trong OpenVZ (một hệ thống container khác, nhưng nay đã không còn phổ biến nhiều nữa). Docker đã giải quyết bằng cách bỏ DAC_READ_SEARCH (cũng như chặn nhưng truy cập vào open_by_handle_at bằng seccomp).
LXC giải quyết bằng cách sử dụng user namespaces, và mặc định chặn những lời gọi hệ thống thông qua seccomp. Chính sách của seccomp đã bị vô hiệu hóa trong cả
privileged và unprivileged của LXC containers. Vì vậy, những người dùng thận trọng được khuyên nên cấu hình unprivileged LXC container và bỏ DAC_READ_SEARCH (và có thể cả SYS_PTRACE).

Abusing Privileged Containers

SYS_RAWIO Abuse

• SYS_RAWIO được cho là dễ lạm dụng vì nó được sử dụng trên toàn bộ kernel và trong một số ngữ cảnh nhạy cảm, điều này dẫn đến việc tìm thấy lỗi container escape trên
  LXC privileged container. Những phiên bản mới của LXC đã bỏ SYS_RAWIO và có thêm những luật AppArmor để chặn truy cập vào “/proc/bus”.
• Từ bên trong containter, ta có thể truy cập vào “control regions” của thiết bị được gắn vào host PCI bus bằng “/proc/bus/pci/interface”. Để truy cập vào “/proc/interface” cần phải có quyền SYS_RAWIO.
  Thậm chí, đường dẫn “/proc” bị chặn bởi AppArmor, container với SYS_RAWIO vẫn có thể tiếp tục truy cập vào interface này thông qua “iopl/ioperm”
  (sau đó sử dụng inb, outb, friends để truy cập vào IO ports). Một điều lưu ý là Docker không bị lỗi này, vì "/proc" thường được gắn cho chế độ chỉ đọc và SYS_RAWIO bị loại bỏ.
  Trong phản hồi về lỗi này, nhóm LXC nhận xét rằng họ coi các vùng privileged container vốn không an toàn, vì có một lỗ hổng đã biết và “không thể sửa” trong các vùng privileged containers.

The ptrace Hole

“Kiểm tra seccomp sẽ không được chạy lại sau khi tracer được thông báo. (Điêu này có nghĩa là hộp cát dựa trên seccomp KHÔNG cho phép sử dụng ptrace, ngay cả sandboxed processes,
maf không thận trọng, ptracer có thể được bị sử dụng để escappe).”

• Bản thân “lỗ hổng bảo mật” là một vấn đề đơn giản về Time-of-Check-to-Time-of-Use (TOCTTOU): seccomp filtering được áp dụng trước khi tracer được thông báo (và trước khi cuộc gọi hệ thống thực sự dược kích hoạt),
  vì vậy pacer có thể sửa đổi các thanh ghi được sử dụng trong lệnh gọi hệ thống (sau khi chúng đã được kiểm tra bởi seccomp) để biến một lệnh gọi hệ thống từ bình thường trở thành “độc hại”.
  Cách mafg docker giải quyết vấn đề này đơn giản là không cho phép sử dụng ptrace trong containers (bằng cách loại bỏ SYS_PTRACE ở chế độ mặc định). Mặc dù seccomp có thể bị vô hiệu hóa bằng cách sử dụng ptrace trong unprivileged contaner,
  việc làm dụng open_by_handle_at sẽ không thành công, vì quá pocess vẫn thiếu DAC_READ_SEARCH trong root namespace. Với việc bổ sung user namespace vào docker, khả năng docker sẽ cho phép sử dụng ptrace bên trong container (mặc dù không chắc
  do sự tập trung gần đây của họ vào seccomp).

• Mặc dù LXC privileged containers vốn đã không an toàn, việc tìm ra các điểm đột phá (breakout) là một bài tập thú vị (và thường chúng có thể làm cho các privileged container an toàn hơn một chút)

Abusing Unprivileged Containers

Tiếp theo, chúng ta sẽ tìm hiểu những điểm yếu của unprivileged containers.

PID Namespacing Info-Leak

Chúng ta sẽ nói đến tệp /proc/sched_debug. pseudo-file này cho phép unprivileged user có thể xem thông tin debug cho Linux scheduler và không biết PID-namespace. Dễ thấy, nó tiết lộ tên và PID của tất cả các tiến trình đang chạy trên hệ thống (và thậm chí biết cả nhóm tác vụ của chúng (cgroup) là gì, giúp xác định được các vùng chứa khác trên hệ thống và hệ thống container nào đang được thực thi). Lỗi này đã được reported cho cả Docker và LXC và nó đã được vá ở Docker.

NET_RAW abuse

Cấu hình phổ biến nhất cho các công ty cung cấp giải pháp PaaS được xây dựng trên container là có nhiều container của khách hàng chạy trên cũng một máy chủ vật lý. Theo mặc định, cả LXC và Docker đều thiết lập container network để tất cả các vùng chứa chia sẻ cùng một Linux virtual bridge. Do đó, những container này sẽ có thể giao tiếp với nhau. Ngay cả khi quyền truy cập mạng trực tiếp này bị vô hiệu hóa (set flag -icc = false cho Docker hoặc sử dụng iptables rules cho LXC), các container vẫn không bị hạn chế đối với việc truy cập link-layer traffic. Đặc biệt, có thể tiến hành một cuộc tấn công giả mạo ARP vào một container khác trong cùng một hệ thống máy chủ, cho phép tấn công full middle-person đối với lưu lượng của container mục tiêu. Chúng ta sẽ có một bài viết nói rõ hơn về cách tần công này.
Sau khi nhận được báo cáo này, LXC team đã đề xuất một số giải pháp, chúng bao gồm:

• Sử dụng LXD với OpenStack để quản lí container networking
• Sử dụng libvirt để quản lí MAC tables của bridges/containers.
• Sử dụng một virtual bridge riêng trên mỗi trust zone hoặc trên mỗi container.

Denial of Service Attacks

User namespaces hoạt động bằng cách “sliding” UIDs giữa user namspace (container) và root namespace (host). Ví dụ, mặc định cài đặt của LXC thì UID 0 bên trong contaner sẽ trở thành UID 100000 trên host. Tuy nhiên, mặc định trên cả LXC và Docker là sử dụng cùng một trang trình bày UID cho tất cả các unprivileged container.
Nói cách khác, các UID giống hệt nhau của các process trong container khác nhau sẽ có giá trị giống nhau trên máy chủ, chỉ được chuyên lên bằng một slide không đổi (tức là tất cả các process đang chạy dưới root bên trong bất kì container nào sẽ đang chạy với UID 100000 trên host). Điều nay làm tăng khả năng ulimit của người dùng khi bị tấn công, vì các khu vực này của kernel không xác định được user namespace. Lưu ý rằng các điều kiện của từ chối dịch vụ (Dos) xảy ra mà không cần user namespace (cũng như điều kiện tương tự của UID máy chủ được chia sẻ đẻ áp dụng). Chúng ta sẽ có một bài viết riêng để thảo luận về cách tấn công này, tuy nhiên chúng ta có một số khái niệm cần lưu ý:

• pending Signals: Đây là giới hạn cho mỗi người dùng về số lượng tín hiệu đang chờ xử lý tối đa có thể được xếp hàng đợi trong tất cả các process của người dùng. process chạy trong một container có thể xếp hàng đợi số lượng tin hiệu đang chờ xử lý tối đa, ngăn các quá trình trong các process khác nhận được tín hiệu đang chờ xử lý. Thực nghiệm cho thấy, điều này làm ảnh hưởng đến cả LXC và Docker.
• Posix Message Queues: giới hạn số lượng tài nuyên tối đa có thể được sử dụng trên hàng đợi thông điệp POSIX. Quá trình chạy trên một container có thể làm cạn kiệt tất cả bộ nhớ hàng đợi thông điệp POSIX có sẵn, ngăn các process trong container khác tạo hoặc gửi thông điệp đến hàng đợi thông điệp POSIX, Thử nghiệm cho thấy việc này vẫn đang hoạt động trên LXC và Docker.
• Max User Processes: giới hạn cho mỗi người dùng về số lượng process tối đa. Điều này có thể dễ dàng được khai thác để tạo ra một Dos đơn giản chống lại các container khác, cũng như máy chủ. Thử nghiệm cho thấy cuộc tấn công này rất thành công trên LXC (và có thể làm hỏng toàn bộ máy chủ) trong khi trên Docker chỉ có thể hạ tất cả vùng chứa Docker (máy chủ vẫn ổn định). Lưu ý, Linux 4.3 đã thêm khả năng giới hạn tài nguyên PID, điều này giúp các hệ thống container giảm thiếu vấn đề này.
• Max Files: Đây là giới hạn cho mỗi người dùng về số lượng bộ mô tả tệp tối đa có thể mở. Tren cả LXC và Docker, đây là một cách dễ dàng để Dos tất cả các container khác đang chạy trên cùng 1 máy chủ.
  Bỏ qua ulimit, hai điều kiện Dos khác có thể được khai thác trong container như sau:
• Disk Space: có lẽ, Dos đơn giản nhất để tấn công hệ thống container là làm cho ổ đĩa bị full. Thử nghiệm, cho thấy điều này đã hoạt động trên LXC và Docker. Không giống như một sô cuộc tấn công Dos ở trên, thường có thể làm hỏng máy chú hoạc gây ra bất ổn đủ để chúng khó dọn dẹp, cách này cung cấp khả năng đơn giản nhất để tạo ra một Dos và sau đó dọn dẹp nó một cách nhanh chóng. Kết hợp với PID Namespacing Info-Leak, điều này có thể cho phép container của kẻ tấn công nhằm mục tiêu đến những người thuê khác trên cùng một máy chủ được chia sẻ, chỉ tạo điều kiện Dos có chọn lọc khi một số container hoặc process khác đang chạy.
• Global File Descriptor Limits: Hệ thống duy trì giới hạn về số lượng bộ mô tả tệp tối đa có sẵn tổn thể (có sẵn tại /proc/sys.fs.filemax, như thảo luận trước đó, container không thể ghi vào). Nếu container không chia sẻ UID và có bộ ulimit về số bộ mô tả tệp mà chúng ta có thể mở, container vẫn có thể cố gắng DoS máy chủ và các contaienr khác bằng cách mở sô lương FD tối đa cho phép khi mỗi người dùng trong user namespace của họ, cung cấp khả năng tiêu thụ FD được khuếch đại rất nhiều. Đây thường là Dos “last line” và chỉ được được thiện nếu các biên pháp giảm nhẹ cho các vector khác (đơn gian hơn) được đưa ra.

Container Engine Vulnerabilities

Một số lỗ hổng và cách khai thác.

Docker Vulnerabilities

Escape via Insecure Configuration

• Bad idea #1: Exposed Docker Socket
• Bad idea #2: –privileged container
• Bad idea #3: Excessive Capabilities
• Bad idea #4: Sensitive mounts

Kernel Exploitation

The security model of containers is predicated on kernel integrity

Dirty CoW (CVE-2016-5195)