Como é que uma montagem bind altera a segurança do contentor num servidor doméstico?

Uma montagem bind altera a segurança do contentor ao dar a um processo dentro do contentor acesso direto a um caminho real no servidor doméstico. Esse acesso contorna parte da fronteira descartável do sistema de ficheiros do contentor e torna os ficheiros do anfitrião, regras de propriedade, etiquetas e opções de montagem parte do modelo de segurança do contentor.

A montagem não é automaticamente insegura. O risco depende de qual caminho do anfitrião é exposto, se o contentor pode escrever nele, qual o utilizador sob o qual o processo corre, e se caminhos sensíveis como o socket do Docker, diretórios de configuração ou pastas de backup estão incluídos.

Que limite é que uma montagem bind ultrapassa?

Normalmente, um contentor vê o seu próprio sistema de ficheiros em camadas e volumes geridos selecionados. Uma montagem bind expõe um caminho real do anfitrião, por isso ficheiros criados ou alterados através desse caminho são alterações ao sistema de ficheiros do anfitrião.

O contentor ainda usa namespaces e o kernel do anfitrião, mas o diretório montado já não está isolado atrás da camada gravável da imagem. A aplicação pode interagir com os mesmos ficheiros que serviços do anfitrião, ferramentas de backup ou outros contentores possam usar.

Isto muda a questão de segurança de apenas 'O que está dentro da imagem?' para 'A que objetos do anfitrião este processo pode aceder?' Um pequeno diretório de media e o sistema de ficheiros raiz do servidor criam exposições muito diferentes mesmo quando a imagem do contentor é idêntica.

Porque é que o acesso gravável expande o raio de impacto?

As montagens bind são normalmente graváveis, a menos que configuradas de outra forma. Uma montagem gravável significa que os processos do contentor podem modificar ficheiros do anfitrião usando as permissões disponíveis para o processo do contentor.

Um servidor de media comprometido pode então encriptar uma biblioteca montada, alterar configurações, substituir scripts ou apagar ficheiros que, de outra forma, sobreviveriam à remoção do contentor. O dano persiste porque os dados vivem fora da camada do contentor.

Snapshots e backups ainda podem ajudar, mas devem conter um estado anterior saudável. os snapshots podem preservar dados já corrompidos, por isso o design da montagem deve limitar os danos antes de ser necessária a história das versões.

Como é que as montagens só de leitura reduzem o risco?

Uma montagem bind somente leitura preserva a visibilidade do anfitrião enquanto bloqueia escritas normais através dessa montagem. Para configuração, entrada de media, certificados ou dados de referência, montagens somente leitura limitam alterações no sistema de ficheiros sem esconder os ficheiros que a aplicação precisa.

Somente leitura é uma forte redução no raio de impacto, mas não é isolamento completo. O contentor ainda pode ler segredos, ficheiros pessoais, metadados ou credenciais se o caminho montado for demasiado amplo.

As aplicações também precisam de locais explicitamente graváveis para bases de dados, uploads, caches ou registos. Montar apenas esses diretórios restritos como graváveis é mais seguro do que expor toda a árvore da aplicação ou o diretório pessoal do utilizador.

Por Que UID, GID e Etiquetas Ainda Importam?

Uma montagem bind mantém a propriedade e as regras de acesso do sistema de ficheiros do anfitrião. O processo do contentor não ganha permissões abstratas de volume; montagens de volumes podem vazar informações do anfitrião através do mapeamento exato do caminho e identidade fornecido.

Quando a raiz do contentor mapeia diretamente para a raiz do anfitrião, um caminho gravável pode ser especialmente perigoso. Executar a aplicação como um UID não-root limita o acesso, mas valores UID e GID incompatíveis podem também criar falhas de permissão que os utilizadores às vezes 'resolvem' com definições chmod demasiado amplas.

SELinux ou outro sistema de controlo de acesso obrigatório adiciona uma segunda decisão além dos bits de modo Unix. Etiquetas corretas podem confinar o contentor mesmo quando a propriedade numérica parece permitir acesso, enquanto desativar a etiquetagem pode remover essa proteção.

Por Que Alguns Caminhos do Anfitrião São Muito Mais Perigosos?

O risco é determinado pela capacidade, não apenas pelo número de ficheiros. Montar o socket Docker expõe o controlo do daemon e pode permitir que um contentor comprometido crie contentores privilegiados ou monte caminhos adicionais do anfitrião.

Montar a raiz do servidor, `/etc`, chaves SSH, configuração de pacotes ou segredos de aplicações pode transformar uma violação num contentor numa acesso mais amplo ao anfitrião. Uma montagem contendo scripts executáveis pode também tornar-se um caminho de persistência se outro processo do anfitrião executar esses ficheiros.

Caminhos de dados comuns ainda podem ser sensíveis. Fotos de família, exportações de gestores de senhas, registos fiscais e backups podem não ajudar um atacante a escapar do contentor, mas a leitura ou eliminação não autorizada já é uma falha grave de segurança.

Como Deve um Servidor Doméstico Projetar Montagens Bind?

Comece com o menor diretório do anfitrião que satisfaça a aplicação. namespaces de montagem isolam as visões do sistema de ficheiros, e cada montagem bind deve ser tratada como uma exceção intencional a essa visão.

Prefira acesso só de leitura para entradas, execute o contentor como um utilizador dedicado não-root, mantenha segredos fora de montagens amplas de dados e evite sockets ou diretórios do sistema a menos que a aplicação realmente os necessite.

Revise o caminho efetivo após a aplicação de links simbólicos, permissões e etiquetas. Um design seguro deve fazer com que a remoção ou comprometimento de um contentor afete apenas o seu próprio limite estreito de dados, enquanto backups independentes preservam outro limite de recuperação.

Perguntas Frequentes

Uma montagem bind é menos segura do que um volume Docker?

Não automaticamente. Uma montagem bind expõe diretamente um caminho escolhido do anfitrião, enquanto um volume gerido é mais abstrato. A segurança depende do âmbito do caminho, acesso de escrita, identidade do processo e etiquetas.

Montar só de leitura torna uma montagem sensível segura?

Impede a modificação normal através dessa montagem, mas o contentor ainda pode ler tudo o que o caminho expõe. Segredos e ficheiros privados não devem ser montados a menos que seja necessário.

Pode um contentor não-root danificar ficheiros montados com bind?

Sim, quando o seu UID ou grupos têm permissão de escrita no caminho do anfitrião. Não-root reduz privilégios, mas não anula a propriedade e regras de acesso reais.

Porque é que montar o socket Docker é perigoso?

O socket controla o daemon Docker. O acesso pode permitir que um contentor inicie cargas de trabalho privilegiadas, inspecione segredos ou monte diretórios adicionais do anfitrião.

Conclusão Final

Uma montagem bind é um orifício deliberado através da fronteira do sistema de ficheiros do contentor. A sua segurança depende da capacidade exposta pelo caminho do anfitrião: dados só de leitura, estado da aplicação gravável, segredos sensíveis ou controlo administrativo. Caminhos estreitos, predefinições só de leitura, identidades não-root, etiquetas corretas e backups independentes evitam que um contentor cause uma falha em todo o servidor doméstico.