Skip to content

Commit

Permalink
docs: add use cases
Browse files Browse the repository at this point in the history
Signed-off-by: Alban Crequy <[email protected]>
  • Loading branch information
alban committed Nov 19, 2020
1 parent b2d4236 commit 2258193
Show file tree
Hide file tree
Showing 2 changed files with 46 additions and 3 deletions.
5 changes: 2 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,8 @@
# Kinvolk Seccomp Agent

The Kinvolk Seccomp Agent is receiving seccomp file descriptors from container runtimes and handling system calls on behalf of the containers.
Its goal is to support different use cases:
- unprivileged container builds (procfs mounts with masked entries)
- support of safe mknod (e.g. /dev/null)

See the [different use cases](docs/usecases.md)

It is possible to write your own seccomp agent with a different behaviour by reusing the packages in the `pkg/` directory.
The Kinvolk Seccomp Agent is only about 100 lines of code. It relies on different packages:
Expand Down
44 changes: 44 additions & 0 deletions docs/usecases.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
---
title: Use cases
weight: 10
description: >
Use cases for the Seccomp Agent.
---

There are several possible use cases for the Seccomp Agent. Not all of them are
implemented.

## Mounting procfs in unprivileged containers

- unprivileged container builds (procfs mounts with masked entries)

## Support for a subset of device mknod

A VPN container might need `/dev/net/tun` but cannot create the device without
`CAP_MKNOD`. Giving this capability to the container could be risky: the
container would be able to abuse the mknod call to get access to disks such as
`/dev/sda`.

The alternative could be to keep the container without `CAP_MKNOD` and add a
seccomp filter on `mknod` to let the Seccomp Agent run `mknod()` on behalf of
the container,

## Userspace emulation of idmapped mounts

When running containers in a user namespace, the files in volumes could appear
to have wrong ownership. This could be fixed with shiftfs or the idmapped mount
patch set. But without that

See:
https://github.com/rootless-containers/subuidless

## Accelerator for slirp4netns

When using slirp4netns as a networking solution for rootless containers, the
performance impact can be big. However, by capturing the `connect` call and
handling it in the seccomp agent, we avoid the performance impact: the network
traffic is no longer routed through a userspace process.

See:
https://github.com/rootless-containers/bypass4netns

0 comments on commit 2258193

Please sign in to comment.