CONTAINING Security

 

bit.ly/2017-containing_security

 

Vincent Batts @vbatts

$> finger $(whoami)
Login: vbatts                           Name: Vincent Batts
Directory: /home/vbatts                 Shell: /bin/bash
Such mail.
Plan:
OHMAN
$> id -Gn
devel opencontainers docker appc redhat golang slackware

Containers

Containers

Kernel's Guarantee:

DON'T BREAK USERSPACE

But what is there to break?

It's sprawling surface to deal with

Context of errors is in kernelspace, not userspace

EPERM

EACCES

Share the host's kernel

Containers:

Crashes and Exploits alike

virtualizing by "namespacing" kernel resources and concepts

Isolation by control groups, syscall filtering, and Linux Security Modules (SELinux, apparmor, etc.)

Kernel Namespaces:

  • mount
  • IPC (message queues, semaphores, shm)
  • UTS (hostname)
  • network
  • PID
  • cgroup
  • user

Kernel Namespaces:

Orthogonal in nature

Varying levels of maturity

Drastically increase complexity and attack surface

Kernel Namespaces:

User Namespace
  • neat step for isolation
  • notable source of root escalations in the kernel
  • still no viable vfs solutions (apart from chown'ing)

OpenShift (and others) are opting for just explicitly running as non-root UID

`runc' can now launch non-root containers directly

Access to Docker daemon means root privilege. Period.

Kernel Namespaces: PID

LSM (Linux Security Modules)
  • Kernel Framework
  • There are several. Most compare SELinux vs. Apparmor
  • (Comprehensive and Complex) vs. (Simple and Narrow)
  • (RBAC and MAC) vs. (just MAC)
Capabilities
Syscalls
grsecurity
  • paid subscription to patches
  • breaks support for kernel
  • RBAC, like SELinux

Lock-Step

Audit

Lock-Step

Signing
  • simple signing vs. Docker notary
  • detached, static vs. isolated service
  • your key rotation process vs. its key rotation process
  • Determine your requirements and use-cases

Cloud

Thanks!

Vincent Batts

@vbatts| vbatts@redhat.com