Qual é a melhor maneira de criar uma lista branca de seccomp para o LXC?

3

Eu tento configurar uma lista de desbloqueio muito restritiva para um contêiner LXC baseado em busybox. Comecei com o arquivo /usr/share/doc/lxc/examples/seccomp-v1.conf do Ubuntu. Parece conter syscalls mais úteis, mas não parece ser mais documentado.

Eu iniciei meus contêineres usando este arquivo e quase tudo funcionou, apenas nginx não começou. Usando strace , descobri que faltavam dois syscalls (algo com *pid* / *gid* ). ausyscall me ajudou a traduzir os nomes para números. Depois disso, nginx começou.

Agora, quero reduzir o arquivo para o que é realmente necessário. Para isso, escrevi um script que percorre o arquivo, remove uma linha temporariamente e testa se todos os recursos ainda funcionam no contêiner. No final, é capaz de criar uma nova lista de permissões (mais restritiva).

Como esse processo é muito demorado, ele estava funcionando todas as noites na semana passada com várias iterações. Atualmente eu fiquei preso porque lxc-attach fails providing an interactive console . Eu tento encontrar uma maneira mais rápida de depuração, o melhor seria se o syslog ou o Lxc registrasse todas as violações do seccomp.

Eu tentei definir audit=1 na linha de comando do kernel, mas apenas uma vez vi as mensagens de auditoria relacionadas ao seccomp no syslog. Lxc em contraste mostra apenas "Container violated seccomp", que não me ajuda a descobrir qual syscall é o problema. Atualização: Se auditd estiver instalado, os registros serão gravados em /var/log/audit/audit.log e o parâmetro da linha de comando do kernel não será mais verificado.

P: Existe uma maneira mais eficiente de gerar uma lista de desbloqueio seccomp útil? E há recomendações sobre o que bloquear ao lado das opções lxc-padrão kexec_load , open_by_handle_at , init_module , finit_module e delete_module ? Existe uma lista de syscalls perigosos?

    
por Daniel Alder 08.10.2015 / 14:07

1 resposta

2

Nesse meio tempo, descobri que o log de auditoria seccomp agora vai para /var/log/audit/audit.log em vez de syslog, depois que eu instalei auditd para obter a ferramenta ausyscall. Sem a ferramenta, os logs não vão a lugar nenhum.

O arquivo contém linhas como

type=SECCOMP msg=audit(1444422928.758:649196): auid=0 uid=100033 gid=100033 ses=1 pid=18459 comm="nginx" exe="/usr/sbin/nginx" sig=31 arch=c000003e syscall=288 compat=0 ip=0x7f2f71555467 code=0x0

Que dizem claramente qual processo e qual syscall violou as regras - isso me ajuda muito.

Mas deixo esta questão em aberto. Ainda existem perguntas sem resposta e ainda estou procurando uma maneira mais eficiente de configurar esse arquivo de lista de permissões do que tentar & erro.

    
por 10.10.2015 / 14:34