[pve-devel] applied-series: [PATCH container 0/4] use seccomp proxy to handle mknod for
Thomas Lamprecht
t.lamprecht at proxmox.com
Fri Jan 31 19:34:30 CET 2020
On 1/30/20 9:27 AM, Wolfgang Bumiller wrote:
> This series adds an `mknod` feature flag for unprivileged containers
> which is handled by setting `lxc.seccomp.proxy.notify` to point to the
> socket where pve-lxc-syscalld is listening (and `….proxy.cookie` to
> the vmid for possible future use).
>
> Currently the daemon handles `mknod()` with the following whitelist:
> c:0:0 - whiteout
> c:1:7 - /dev/full
> c:1:3 - /dev/null
> c:1:5 - /dev/zero
> c:1:8 - /dev/random
> c:1:9 - /dev/urandom
> c:5:0 - /dev/tty
> c:5:1 - /dev/console
>
> Currently the seccomp interface requires us to either completely
> handle a syscall or not catch it at all. (Iow. you can't just allow
> parts of a syscall manually and tell the kernel to "do its thing" for
> the cases you don't want to handle). For `mknod` this is not an issue
> since the kernel won't allow it at all in user namespaces.
>
> Later when we get a kernel >=5.5 we could also start partially
> handling some syscalls (eg. mount, but that'll only be feasable with
> the old mount api), and send cases we don't want to handle "back to the
> kernel".
>
> Wolfgang Bumiller (4):
> add mknod feature flag
> add a check_kernel_release helper
> mask 'mknod' feature by kernel version
> set lxc.seccomp.notify.cookie to the vmid
>
> src/Makefile | 1 -
> src/PVE/LXC.pm | 116 ++++++++++++++++++++++++++++++++++++------
> src/PVE/LXC/Config.pm | 8 +++
> 3 files changed, 109 insertions(+), 16 deletions(-)
>
applied series, much thanks! I dropped the "add a check_kernel_release helper"
and added it to pve-common's procfs, where we had already an "get parsed kernel
version", and squashed the use of that in your "mask 'mknod' feature by kernel
version" patch, FYI.
More information about the pve-devel
mailing list