Skip to content

Commit 2258193

Browse files
committed
docs: add use cases
Signed-off-by: Alban Crequy <alban@kinvolk.io>
1 parent b2d4236 commit 2258193

File tree

2 files changed

+46
-3
lines changed

2 files changed

+46
-3
lines changed

README.md

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,8 @@
11
# Kinvolk Seccomp Agent
22

33
The Kinvolk Seccomp Agent is receiving seccomp file descriptors from container runtimes and handling system calls on behalf of the containers.
4-
Its goal is to support different use cases:
5-
- unprivileged container builds (procfs mounts with masked entries)
6-
- support of safe mknod (e.g. /dev/null)
4+
5+
See the [different use cases](docs/usecases.md)
76

87
It is possible to write your own seccomp agent with a different behaviour by reusing the packages in the `pkg/` directory.
98
The Kinvolk Seccomp Agent is only about 100 lines of code. It relies on different packages:

docs/usecases.md

Lines changed: 44 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
---
2+
title: Use cases
3+
weight: 10
4+
description: >
5+
Use cases for the Seccomp Agent.
6+
---
7+
8+
There are several possible use cases for the Seccomp Agent. Not all of them are
9+
implemented.
10+
11+
## Mounting procfs in unprivileged containers
12+
13+
- unprivileged container builds (procfs mounts with masked entries)
14+
15+
## Support for a subset of device mknod
16+
17+
A VPN container might need `/dev/net/tun` but cannot create the device without
18+
`CAP_MKNOD`. Giving this capability to the container could be risky: the
19+
container would be able to abuse the mknod call to get access to disks such as
20+
`/dev/sda`.
21+
22+
The alternative could be to keep the container without `CAP_MKNOD` and add a
23+
seccomp filter on `mknod` to let the Seccomp Agent run `mknod()` on behalf of
24+
the container,
25+
26+
## Userspace emulation of idmapped mounts
27+
28+
When running containers in a user namespace, the files in volumes could appear
29+
to have wrong ownership. This could be fixed with shiftfs or the idmapped mount
30+
patch set. But without that
31+
32+
See:
33+
https://github.com/rootless-containers/subuidless
34+
35+
## Accelerator for slirp4netns
36+
37+
When using slirp4netns as a networking solution for rootless containers, the
38+
performance impact can be big. However, by capturing the `connect` call and
39+
handling it in the seccomp agent, we avoid the performance impact: the network
40+
traffic is no longer routed through a userspace process.
41+
42+
See:
43+
https://github.com/rootless-containers/bypass4netns
44+

0 commit comments

Comments
 (0)