Awesome Linux Containers

Foundations

Specifications

Clouds

Hypervisors

Containers

Sandboxes

Partial Access

Security

levels of security problems

regular application

calways untrusted -> know it
csuid bit -> mount with nosuid
limit available syscall -> seccomp-bpf, grsec
leak to another container (bug in namespaces, filesystem) -> user namespaces with different uid inside for each cotainer: 1000 in container - 14293 and 15398 outside; security modules like selinux or apparmor

system services like cron, ssh

run as root -> isolate via bastion host or vm
using /dev -> "devices" control group
The following device nodes are created in the container by default.
The Docker images are also mounted with nodev, which means that even if a device node was pre-created in the image, it could not be used by processes within the container to talk to the kernel.
/dev/console,/dev/null,/dev/zero,/dev/full,/dev/tty*,/dev/urandom,/dev/random,/dev/fuse
root calls -> capabilities (cap_sys_admin warning!)
Here is the current list of capabilities that Docker uses: chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap, and audit_write.
Docker removes several of these capabilities including the following:
CAP_SETPCAP Modify process capabilities
CAP_SYS_MODULE Insert/Remove kernel modules
CAP_SYS_RAWIO Modify Kernel Memory
CAP_SYS_PACCT Configure process accounting
CAP_SYS_NICE Modify Priority of processes
CAP_SYS_RESOURCE Override Resource Limits
CAP_SYS_TIME Modify the system clock
CAP_SYS_TTY_CONFIG Configure tty devices
CAP_AUDIT_WRITE Write the audit log
CAP_AUDIT_CONTROL Configure Audit Subsystem
CAP_MAC_OVERRIDE Ignore Kernel MAC Policy
CAP_MAC_ADMIN Configure MAC Configuration
CAP_SYSLOG Modify Kernel printk behavior
CAP_NET_ADMIN Configure the network
CAP_SYS_ADMIN Catch all
uses /proc, /sys -> remount ro, drop cap_sys_admin; security modules like selinux or apparmor; some part of this fs are "namespace-aware"
Docker mounts these file systems into the container as "read-only" mount points.
. /sys
. /proc/sys
. /proc/sysrq-trigger
. /proc/irq
. /proc/bus
Copy-on-write file systems
Docker uses copy-on-write file systems. This means containers can use the same file system image as the base for the container. When a container writes content to the image, it gets written to a container specific file system. This prevents one container from seeing the changes of another container even if they wrote to the same file system image. Just as important, one container can not change the image content to effect the processes in another container.
uid 0 -> user namespaces, uid 0 mappet to random uid outside

system services like devices, network, filesystems

root -> more of services should work on host outside; isolate sensitive functions, run as non-privilaged context
full privilages -> isolate on kernel level

kernel drivers, network stack, security policies

absolute privilages -> run it in separate vm

general like immutable infrastructure

container is ro
write to small separate rw nosuid part

src
src

software for security

Things are better. For example, most modern container technologies can make use of Linux's built-in security tools such as:
AppArmor, SELinux and Seccomp policies;
Grsecurity;
Control groups (cgroups);
Kernel namespaces
src

Sure, you're deploying seccomp, but you can't use selinux inside your container, because the policy isn't per-namespace (?? lxc uses apparmore for each container...)
sVirt - selinux for kvm
src

Major kernel subsystems are not namespaced like:
SELinux
Cgroups
file systems under /sys
/proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus

Devices are not namespaced:
/dev/mem
/dev/sd* file system devices
kernel modules

If you can communicate or attack one of these as a privileged process, you can own the system.
src

6.8 KiB Raw Blame History