Quão perigoso é não carregar regras 'seccomp' para contêineres LXC?

Question

Contexto

Na minha "missão" para obter o LXC para ser executado no Raspbian Posso ser forçado a desativar o carregamento do seccomp configuração na inicialização do contêiner, comentando em /usr/share/lxc/config/debian.common.conf :

# Blacklist some syscalls which are not safe in privileged
# containers
#  lxc.seccomp = /usr/share/lxc/config/common.seccomp

Como (a.t.m.) somente que o contêiner é iniciado (caso contrário, um erro é gerado).

Desativar essa configuração de segurança básica tão strongmente vinculada à conteinerização / sandboxing é, de certa forma, invalidar o propósito do LXC. Do ponto de vista da segurança / estabilidade, gostaria muito de manter a lista negra na maioria das chamadas do sistema ao executar os contêineres do LXC (conforme configurado pelos padrões do LXC em /usr/share/lxc/config/common.seccomp ):

2
blacklist
[all]
kexec_load errno 1
open_by_handle_at errno 1
init_module errno 1
finit_module errno 1
delete_module errno 1

Perguntas

Não faz o 'carregamento de regras seccomp para o rendimento de contêineres LXC':

1. questões de segurança significativas *?
2. algum outro problema técnico (aplicativo ou estabilidade)?

* Assumindo que eu sou o único usando o sistema "mãe" e seus contêineres LXC (caso contrário, seria evidente ..)

    

Answer 1

Bem, as regras seccomp impedem que um contêiner modifique o kernel do host. Sem eles, o UID 0 em um container pode usar o kexec (se é que isso funciona em Raspbian, não tenho certeza) para carregar um novo kernel (aparentemente não para iniciá-lo) e insmod / rmmod para carregar / descarregar módulos entre outras coisas, essas syscalls não levam em conta os namespaces dos usuários corretamente.

Se isso é um problema de segurança significativo, você só precisa ter em mente que agora o UID 0 no contêiner pode se tornar efetivamente o UID 0 fora do contêiner, ou seja, é possível que o root escape do contêiner carregando um módulo criado por exemplo.