Contentor de aplicação Docker vs. LXC dedicado para serviços domésticos privilegiados: qual contém mais riscos?
Escolha um contentor Docker com o mínimo de privilégios quando o serviço é distribuído como uma imagem e necessita apenas de ficheiros, portas, dispositivos e capacidades mapeados de forma restrita. Escolha um LXC dedicado sem privilégios quando o serviço necessita de um ambiente Linux mais completo, de integração direta com o sistema ou de vários processos relacionados sob um convidado gerido separadamente. Nenhum dos modelos continua a constituir um limite de segurança significativo depois de expor diretórios amplos do anfitrião, o socket do Docker, dispositivos sem restrições ou poderes de raiz ao nível do anfitrião.
Compare primeiro limites de implementação equivalentes
Docker e LXC são tecnologias de contentores Linux que partilham o kernel do anfitrião, mas normalmente empacotam unidades diferentes. O Docker isola normalmente uma aplicação ou uma stack Compose. O LXC cria um contentor de sistema leve com os seus próprios utilizadores, base de dados de pacotes, serviços e sistema de ficheiros do sistema operativo.
A comparação justa é, portanto, entre uma aplicação Docker executada diretamente num anfitrião Linux e o mesmo serviço doméstico privilegiado instalado dentro de um LXC dedicado. Não se trata do Docker dentro do LXC versus o próprio LXC, nem de qualquer um dos modelos de contentor versus uma máquina virtual com um kernel separado.
A comparação existente da ZimaSpace entre instalações Docker e nativas dentro do LXC aborda o empacotamento e a manutenção. Este artigo isola a decisão de segurança quando o serviço solicita privilégios que enfraquecem os limites normais dos contentores.
| Eixo de segurança | Contentor de aplicação Docker | Contentor de sistema LXC dedicado |
|---|---|---|
| Unidade de isolamento principal | Processo da aplicação e as respetivas dependências empacotadas | Espaço de utilizador Linux com vários serviços e utilizadores |
| Kernel do anfitrião | Partilhado com o anfitrião | Partilhado com o anfitrião |
| Mapeamento da raiz | Com privilégios de raiz por predefinição, exceto quando são utilizados espaços de nomes de utilizadores ou o modo rootless | Pode ser privilegiado ou mapear a raiz do contentor para um UID de anfitrião sem privilégios |
| Acesso a dispositivos | É possível mapear dispositivos individuais; o modo privilegiado expõe-nos de forma abrangente | Os nós de dispositivos e as permissões do anfitrião podem ser mapeados para o convidado |
| Ficheiros do anfitrião | Os bind mounts expõem diretamente caminhos selecionados do anfitrião à aplicação | Os bind mounts expõem caminhos ao convidado e a todos os processos autorizados dentro dele |
| API administrativa | O socket do Docker pode conceder controlo sobre o anfitrião Docker | Nenhum socket de daemon equivalente, a menos que outro runtime esteja instalado dentro do LXC |
| Mais adequado | Aplicação empacotada com privilégios rigorosamente limitados | Serviço que requer integração com o sistema operativo dentro dos limites de um convidado sem privilégios |
Comece pelo privilégio exato de que o serviço necessita
“Serviço doméstico privilegiado” pode significar várias permissões não relacionadas: ler um dispositivo série USB, utilizar um nó de renderização da GPU, controlar uma interface de rede, montar um sistema de ficheiros, associar uma porta baixa, aceder a Bluetooth, ler dados SMART ou gerir outros contentores.
Conceda a menor capacidade, dispositivo, caminho e modo de rede que permitam o funcionamento do serviço. A explicação da Snyk sobre o modo de contentor privilegiado salienta que o acesso totalmente privilegiado expõe todos os dispositivos do anfitrião e poderes quase equivalentes aos do anfitrião. Não deve substituir a investigação da única permissão em falta.
Se um serviço só precisar de /dev/dri/renderD128, um caminho serial por ID ou um diretório de configuração só de leitura, tanto o Docker como o LXC podem expor esse recurso limitado. A diferença de segurança torna-se relevante quando a implementação exige capacidades amplas ou múltiplas superfícies do anfitrião.
O LXC não privilegiado cria um limite de mapeamento do root mais forte
Num LXC não privilegiado, o UID 0 dentro do convidado é mapeado para um UID subordinado comum no anfitrião Proxmox. Um processo pode aparentar ser root dentro do contentor sem ter a identidade de root do anfitrião fora do seu namespace de utilizadores. Isto reduz as consequências de muitos erros de permissões de ficheiros e de algumas fugas de contentores.
O projeto Linux Containers descreve o mapeamento do root no LXC não privilegiado como o principal limite de segurança do design, com AppArmor, seccomp e capacidades a acrescentarem restrições adicionais aos processos e aos recursos do anfitrião.
A vantagem depende de manter o contentor sem privilégios. Um LXC privilegiado não utiliza o mesmo remapeamento de UID, pelo que o root dentro do convidado corresponde muito mais diretamente ao root no anfitrião. Converter para o modo privilegiado apenas para simplificar montagens ou dispositivos pode eliminar a razão pela qual o LXC parecia mais seguro.
O Docker pode reduzir o risco do root sem mover a aplicação para o LXC
Os contentores Docker não têm de ser executados com um daemon rootful sem restrições e um utilizador de aplicação root. Uma imagem de contentor pode especificar um utilizador não root, o runtime pode remover capacidades, os sistemas de ficheiros podem ser só de leitura e os namespaces de utilizadores podem remapear as identidades do contentor.
O modo sem root do Docker executa tanto o daemon como os contentores sem privilégios de root no anfitrião. Isto pode reduzir os riscos do daemon e do runtime quando a aplicação e as funcionalidades de armazenamento ou rede necessárias suportam as limitações do modo sem root.
O Docker continua a ser a melhor fronteira quando a aplicação já está bem empacotada e precisa apenas de um privilégio estritamente definido. Movê-la para um LXC completo acrescenta outro sistema operativo para atualizar sem reduzir automaticamente o recurso mapeado disponível para a aplicação comprometida.
O Socket do Docker Pode Eliminar a Fronteira da Aplicação
Alguns painéis, atualizadores automáticos, ferramentas de cópia de segurança e serviços de monitorização solicitam acesso a /var/run/docker.sock. O socket permite que um cliente instrua o daemon do Docker do anfitrião a criar contentores, montar caminhos do anfitrião, disponibilizar dispositivos e alterar redes. Por conseguinte, um serviço comprometido pode controlar indiretamente o anfitrião sem explorar uma fuga do kernel.
A análise da Netdata explica por que motivo o acesso ao socket do Docker equivale a administrar o anfitrião: o processo pede ao daemon privilegiado para executar ações poderosas no anfitrião em seu nome, sem uma fuga convencional do contentor.
Este é o primeiro limite de paragem. Se o serviço exigir acesso irrestrito ao socket do Docker, comparar o isolamento normal do Docker com o isolamento normal do LXC é enganador. Trate o serviço como um administrador do anfitrião, restrinja a respetiva API através de um proxy concebido para esse fim, se possível, isole-o de redes não confiáveis e proteja as respetivas credenciais em conformidade.
O Mapeamento de Dispositivos Favorece o Modelo com Menos Camadas de Permissões
Uma GPU, um controlador USB, um sintonizador, um acelerador Coral, uma UPS ou um adaptador série podem ser disponibilizados a qualquer uma das implementações. No Docker direto, o anfitrião disponibiliza o dispositivo ao contentor da aplicação. No LXC, o Proxmox disponibiliza o dispositivo ao contentor do sistema, que depois executa o serviço nativamente ou pode voltar a disponibilizá-lo ao Docker aninhado.
O LXC dedicado pode ser mais simples quando vários processos relacionados precisam do mesmo dispositivo e o acesso deve ser gerido por utilizadores ou grupos Linux. O Docker pode ser mais simples quando uma imagem precisa de um único dispositivo e o mapeamento é descrito diretamente no Compose.
Evite dar a qualquer um dos contentores acesso a todos os dispositivos apenas porque a permissão de um dispositivo é difícil de configurar. O Proxmox observa que a segurança do LXC combina namespaces, AppArmor, seccomp e restrições de dispositivos. O acesso amplo a dispositivos elimina parte desse limite em camadas, tal como o modo privilegiado do Docker.
As montagens bind do anfitrião transferem o risco em direções diferentes
Uma montagem bind do Docker expõe diretamente o caminho do anfitrião selecionado à aplicação. Uma montagem com permissões de escrita que contenha fotografias, cópias de segurança, configuração ou o estado de outras aplicações dá a um contentor comprometido os mesmos direitos de modificação que o utilizador do anfitrião mapeado tem nesse caminho.
Uma montagem bind do LXC expõe o caminho ao convidado, onde vários serviços e utilizadores administrativos podem aceder-lhe de acordo com os mapeamentos de UID e GID. O limite adicional do sistema pode ajudar a organizar as permissões, mas também aumenta o conjunto de processos dentro do convidado que poderiam alcançar os dados.
Utilize montagens só de leitura sempre que possível, separe a configuração dos dados em massa e evite mapear a raiz do anfitrião, /proc, /sys, /dev, ou diretórios de dados do Docker de forma ampla. Se o serviço tiver de reescrever dados protegidos do NAS, o isolamento da aplicação não substitui instantâneos e cópias de segurança independentes.
Os privilégios de rede podem criar um raio de impacto maior do que o acesso ao sistema de ficheiros
Serviços domésticos como gateways VPN, filtros DNS, ferramentas de descoberta de rede, integrações com o Home Assistant e sistemas de monitorização podem solicitar rede do anfitrião, sockets raw, captura de pacotes, modificação da firewall ou acesso a várias VLAN. Estas capacidades podem expor tráfego e permitir que o serviço influencie outros dispositivos.
Um contentor Docker com rede do anfitrião perde a separação de rede ao nível das portas, enquanto capacidades adicionais como NET_ADMIN ou NET_RAW aumentam o que um comprometimento pode fazer. Um LXC com a sua própria interface virtual pode fornecer um endereço separado e uma política de firewall própria, mas um convidado privilegiado ou ligado a várias redes pode ainda assim alcançar redes sensíveis.
Escolha o limite que lhe permite definir o percurso de rede mais restrito. Uma VLAN separada, um endereço dedicado, regras de firewall explícitas e a ausência de acesso à gestão do NAS reduzem frequentemente o risco mais do que mudar de tecnologia de contentores, mantendo o serviço em todas as redes fidedignas.
O LXC privilegiado e o Docker privilegiado falham de formas diferentes
Um contentor Docker totalmente privilegiado recebe amplas capacidades Linux e acesso a dispositivos através de um daemon Docker executado como root. Um LXC privilegiado proporciona a um espaço de utilizador convidado completo uma relação de identidade muito mais próxima da do root do anfitrião. Nenhum dos dois deve ser tratado como um contentor de aplicação não privilegiado comum.
As orientações de segurança da Tigera alertam para o facto de o modo privilegiado do Docker contornar controlos de isolamento importantes. As discussões na comunidade Proxmox alertam igualmente para o facto de ativar o nesting ou permitir um acesso abrangente ao sistema de ficheiros do anfitrião dentro do LXC poder expor as superfícies /proc e /sys do anfitrião quando configurado sem os devidos cuidados.
Se o serviço exigir realmente poderes equivalentes aos do root do anfitrião, uma VM com um kernel dedicado poderá fornecer um limite de contenção mais claro. O custo adicional de memória e armazenamento pode justificar-se quando o serviço está exposto à Internet, processa dados não fiáveis, carrega controladores adjacentes ao kernel ou administra outras cargas de trabalho.
As Atualizações e a Recuperação Determinam se o Isolamento Continua a Ser Utilizável
O Docker torna o pacote da aplicação substituível. Recrie o contentor a partir de uma imagem ou digest fixado, restaure a configuração e os dados persistentes e reaplique os mesmos privilégios restritos. Isto é valioso quando a política de segurança está visível no Compose, em vez de depender de comandos de shell memorizados.
Um LXC dedicado torna o ambiente operativo substituível como um único convidado Proxmox. A base de dados de pacotes, os ficheiros de serviço, os utilizadores e os mapeamentos de dispositivos podem ser salvaguardados em conjunto. A recuperação é simples quando as montagens de ligação, os mapeamentos de UID, os dispositivos do anfitrião e as regras de rede estão documentados fora do convidado.
A comparação da ZimaSpace entre os limites de recuperação de uma VM Docker e de um LXC por aplicação apresenta o teste operacional complementar. Um limite de segurança menor só é útil quando pode ser restaurado sem recriar manualmente privilégios abrangentes.
Execute um Teste de Redução de Privilégios Antes de Escolher Docker ou LXC
- Faça uma lista de todos os dispositivos, caminhos do anfitrião, capacidades, redes, APIs e funcionalidades do kernel solicitados pelo serviço.
- Remova o modo totalmente privilegiado e volte a adicionar cada requisito individualmente.
- Execute a aplicação como um utilizador sem privilégios de root ou dentro de um LXC não privilegiado, quando suportado.
- Substitua as montagens com permissões de escrita abrangentes por caminhos restritos, só de leitura ou específicos do conjunto de dados.
- Remova o acesso ao socket do Docker ou coloque um proxy restrito entre o serviço e o daemon.
- Teste as premissas de comprometimento, verificando que ficheiros, dispositivos e redes do anfitrião continuam acessíveis.
- Restaure o serviço num anfitrião Docker ou LXC limpo, utilizando apenas uma configuração com versões fixadas.
Não avalie a segurança apenas pelo número de camadas. Avalie as permissões efetivas disponíveis depois de adicionar todos os dispositivos, montagens, capacidades, sockets e redes necessários. Um contentor simples com acesso restrito pode ser mais seguro do que um design aninhado complexo com várias exceções.
Que fronteira é adequada para o serviço doméstico privilegiado?
Escolha uma aplicação Docker em contentor quando
Escolha Docker quando o serviço for distribuído como uma imagem, precisar de um ou dois dispositivos ou montagens explícitos e puder ser executado sem --privileged, acesso irrestrito ao socket do Docker ou uma rede ampla do anfitrião. Fixe as versões, remova capacidades, utilize sistemas de ficheiros apenas de leitura sempre que possível e mantenha os dados persistentes explicitamente definidos.
Escolha um LXC dedicado sem privilégios quando
Escolha LXC quando o serviço precisar de um ambiente Linux mais completo, de vários daemons relacionados, de integração direta com o systemd ou de permissões complexas para grupos de dispositivos. Preserve o mapeamento do espaço de nomes de utilizadores, mantenha as restrições do AppArmor e do seccomp e documente todas as montagens e todos os mapeamentos de dispositivos do anfitrião.
Escolha antes uma VM quando
Use uma VM quando a carga de trabalho precisar de um controlo equivalente ao root do anfitrião, carregar controladores invulgares, administrar outras cargas de trabalho, aceitar dados públicos não confiáveis ou não puder ser executada sem amplos privilégios no sistema de ficheiros e na rede. Um kernel separado cria uma fronteira mais forte do que adicionar mais exceções a um contentor com kernel partilhado.
Perguntas frequentes
Um LXC privilegiado é mais seguro do que um contentor Docker privilegiado?
Não como regra geral. Ambos enfraqueceram controlos importantes de isolamento, mas expõem os privilégios de forma diferente. Avalie o mapeamento de UID, os dispositivos, as montagens, as capacidades, o acesso à rede, o AppArmor, o seccomp e as APIs do daemon, em vez de confiar no rótulo do contentor.
Executar Docker dentro de um LXC sem privilégios acrescenta outra camada de segurança?
Pode acrescentar o mapeamento de UID entre o LXC e o anfitrião Proxmox, mas o Docker aninhado pode exigir funcionalidades de nesting, capacidades adicionais, exceções no sistema de ficheiros ou mapeamentos de dispositivos. Essas alterações podem anular o benefício. Uma VM é mais clara quando é necessária uma separação forte em relação ao anfitrião.
Os serviços domésticos disponíveis apenas na LAN precisam de contentores sem privilégios?
Sim, quando o comprometimento puder ocorrer através de outro dispositivo da LAN, de uma interface Web vulnerável, de conteúdos multimédia ou documentos maliciosos, de imagens da cadeia de fornecimento ou de credenciais expostas. Colocar o serviço apenas na LAN reduz alguma exposição, mas não torna inofensivo o acesso de root ao anfitrião.
Veredicto final
Use Docker quando uma aplicação empacotada puder ser executada com privilégios estritamente definidos e sem interfaces administrativas do anfitrião. Use um LXC sem privilégios quando um serviço precisar de um sistema Linux mais completo, preservando o mapeamento de root e o acesso controlado a dispositivos. Se qualquer uma das opções exigir amplos privilégios de root no anfitrião, sockets sem restrições ou acesso de escrita a dados críticos, deixe de comparar contentores e coloque o serviço atrás de uma fronteira mais forte, como uma VM ou uma máquina separada.
Produtos recomendados
Comparações de Produtos
Mais para Ler
Túnel VPS vs. Encaminhamento de portas doméstico para serviços autoalojados públicos: qual o caminho de entrada mais fácil de controlar?
Use o encaminhamento de portas para o caminho direto mais simples; use um túnel VPS quando a CGNAT, a privacidade do endereço, a entrada...
Router de consumo vs. firewall dedicado para um laboratório doméstico segmentado: quando deve separar o gateway?
Mantenha o router para consumidores enquanto a segmentação se mantiver simples; mude para uma firewall dedicada quando as políticas, a visibilidade, as interfaces ou...
Laboratório de camada 2 vs VLANs encaminhadas à medida que o laboratório doméstico cresce: quando deve o gateway aproximar-se da periferia?
Mantenha a Camada 2 enquanto uma gateway e alguns trunks permanecerem claros; encaminhe mais perto da periferia quando a extensão da VLAN, o âmbito...
