O CageFS no dia-a-dia da hospedagem: isolamento do sistema de ficheiros entre contas de clientes

Por que é que as contas de alojamento precisam de isolamento

No alojamento partilhado, vários clientes alojam os seus sites no mesmo servidor. Se um script na conta A for comprometido, pode tentar recolher informações sobre o ambiente e aceder a ficheiros de outras contas. Isso pode incluir ficheiros de configuração com dados de acesso ou dados pessoais. A separação das contas visa dificultar esse tipo de acesso, apesar de a infraestrutura ser partilhada.

Estão presentes Visibilidade e direitos de acesso questões diferentes. O nome de um diretório pode estar visível, embora a leitura do seu conteúdo seja impedida pelas permissões do ficheiro. Por outro lado, uma visualização restrita, por si só, não é suficiente para substituir direitos cuidadosamente definidos: o que estiver acessível no ambiente deve continuar a ser devidamente protegido.

CageFS adiciona às autorizações um ambiente de sistema de ficheiros específico para cada utilizador. Um processo no contexto previsto não tem simplesmente a mesma visão do anfitrião que um administrador. Desta forma, um script executado a partir da conta A não deve poder explorar facilmente os diretórios de outras contas. As áreas que estão efetivamente visíveis dependem da configuração.

Para os operadores, isto representa um Camada de separação, não há garantia contra quaisquer repercussões noutros clientes. Erros nos serviços partilhados, autorizações demasiado amplas ou uma integração incompleta dos serviços podem afetar o efeito de proteção. Por isso, o isolamento deve ser verificado no local onde os programas dos clientes são efetivamente executados, e não apenas com base numa configuração na área de administração.

Para os clientes de alojamento, esta distinção também é importante: o facto de uma aplicação própria não ter acesso a um diretório externo descreve, em primeiro lugar, apenas o seu contexto de execução específico. Isso não comprova nem a configuração de todos os serviços nem a proteção de todas as outras contas. O fornecedor continua a ser responsável pela configuração e controlo globais.

Como o CageFS organiza a visualização do sistema de ficheiros

O CageFS oferece aos utilizadores uma visão própria do sistema de ficheiros. A base é o Esqueleto: um modelo com ficheiros e diretórios disponibilizados para o ambiente em questão. As partes necessárias são incorporadas; o diretório pessoal do utilizador também é integrado no seu ambiente. A árvore de diretórios visível não é, portanto, simplesmente uma cópia inalterada da visualização do anfitrião.

A integração pode ser ilustrada com um exemplo prático: um administrador instala um programa no anfitrião, mas um processo do cliente não o encontra no seu ambiente. Isso não significa automaticamente que se trate de um erro de instalação. O programa pode estar presente no anfitrião sem estar disponível no esqueleto ou através das integrações previstas para o cliente.

Por outro lado, cada ficheiro adicional disponibilizado alarga o ambiente que um processo pode ver. O mesmo se aplica a um diretório montado. Os administradores devem, por isso, ponderar as necessidades funcionais face à visibilidade adicional: uma aplicação pode necessitar de uma determinada ferramenta e das suas dependências, mas não necessariamente de um diretório inteiro do anfitrião.

O Configuração do Mount determina quais as partes do sistema de ficheiros que aparecem no ambiente. No entanto, não é o único fator que determina se um processo pode ler, alterar ou executar um ficheiro visível. Para isso, continuam a ser relevantes, entre outros aspetos, a propriedade e as autorizações. Um caminho visível não é, portanto, sinónimo de acesso de escrita autorizado.

O diretório pessoal continua a ser particularmente importante no dia-a-dia da hospedagem: é aí que se encontram, normalmente, os ficheiros da respetiva conta. A integração permite o acesso no contexto previsto, enquanto o resto da visualização é limitada. No entanto, o facto de uma aplicação específica conseguir aceder a todos os ficheiros necessários depende da sua configuração e dos caminhos efetivamente disponíveis.

CageFS, LVE e riscos comuns

O CageFS e o LVE resolvem problemas diferentes. O CageFS define a visão do sistema de ficheiros e o contexto de execução de um utilizador; LVE serve para monitorizar e limitar recursos como a CPU, a memória e as entradas e saídas. Um processo com visibilidade limitada do sistema de ficheiros pode continuar a necessitar de recursos. Por outro lado, um limite de recursos, por si só, não impede o acesso a ficheiros partilhados indevidamente.

Um painel de controlo de alojamento cumpre mais uma função: entre outras coisas, gere contas e pode integrar componentes do CloudLinux. No entanto, a mera instalação de um painel não garante que todos os processos Web, todos os shells e todas as tarefas agendadas sejam executados no contexto CageFS previsto. Os operadores devem verificar a integração adequada para a sua plataforma específica.

O CageFS não consiste numa máquina virtual própria para cada conta. As contas continuam a utilizar um kernel comum e podem depender de serviços geridos em conjunto. Uma vulnerabilidade ou uma configuração incorreta nestes componentes partilhados continua, por isso, a fazer parte do modelo de ameaças. O isolamento do sistema de ficheiros reduz uma parte do ambiente visível, mas não substitui a proteção e a manutenção do anfitrião.

Mesmo no âmbito de uma conta devidamente isolada, continuam a existir riscos. Uma aplicação vulnerável pode, por exemplo, revelar os seus próprios dados; credenciais de acesso roubadas podem permitir que um atacante obtenha acesso no âmbito da conta em questão. O CageFS não corrige código de aplicação inseguro nem direitos excessivamente amplos sobre ficheiros acessíveis dentro dessa conta.

Para uma estratégia de segurança robusta, é, portanto, necessário que as camadas se complementem: integrar corretamente contas e serviços, controlar os direitos de acesso aos ficheiros, definir limites de recursos adequados e manter as aplicações atualizadas. O nível de proteção resultante depende da configuração efetiva e dos serviços em funcionamento. O nome de um único componente não substitui esta verificação.

Analisar as contas e os sites separadamente

Duas contas de cliente no mesmo servidor são um caso diferente de dois sítios Web dentro de uma mesma conta. O CageFS disponibiliza um ambiente específico para cada utilizador, limitando assim a visibilidade de uma conta no sistema de ficheiros. No entanto, isso não significa que cada sítio Web dentro dessa conta tenha os seus próprios limites no sistema de ficheiros.

Se uma agência gerir vários projetos na mesma conta de alojamento, as suas aplicações podem aceder a ficheiros de outros projetos, dependendo do contexto de execução e das autorizações. Se um atacante conseguir aceder a um site através de um plugin vulnerável, é, por isso, necessário verificar quais os ficheiros de configuração e dados de acesso que estão disponíveis nessa conta. A separação em relação a uma segunda conta de cliente não responde a esta questão.

Para um resultado mais fino Separação do site O CloudLinux documenta, através do CloudLinux Isolates, um isolamento adicional do sistema de ficheiros baseado em domínios. A sua disponibilidade depende da disponibilidade concreta do produto, da versão e da integração com o painel de controlo. Verifique estes pré-requisitos para a sua própria pilha de alojamento, em vez de concluir que existe uma separação entre os domínios apenas com base na ativação do CageFS.

Os limites de LVE relacionados com domínios são também uma funcionalidade distinta, com os seus próprios pré-requisitos. Por conseguinte, um limite adicional do sistema de ficheiros não significa automaticamente que a CPU ou a memória sejam limitadas separadamente para cada domínio. O artigo sobre Isolamento de sites do CloudLinux aprofunda a diferença entre o nível da conta e o nível do site; os requisitos da variante do produto utilizada continuam a ser determinantes para a configuração.

Para o planeamento, vale a pena começar por fazer um balanço da situação: que sites partilham uma conta, que ficheiros têm de ser partilhados e que dados de acesso devem permanecer separados? A partir daí, é possível determinar se contas separadas ou um isolamento baseado no domínio, se disponível, se adequam ao modelo operacional. Ambas as variantes exigem uma análise dos percursos de utilização efetivos.

Verificar o estado do Pilot e do CageFS

Antes de iniciar um projeto-piloto, enquanto operador, deve verificar se a versão do sistema operativo utilizada é suportada, se os pacotes necessários e a licença estão disponíveis e se o Painel de Controlo está devidamente integrado. O facto de um painel ter suporte documentado não significa que todas as funcionalidades funcionem da mesma forma em todas as combinações. Regista também quais as aplicações e ferramentas necessárias para as contas de teste selecionadas.

Começa com contas de teste expressamente autorizadas e uma seleção razoável de aplicações típicas. Verifica os seus diretórios principais, os programas necessários e os caminhos de execução relevantes antes de criar mais contas. Para a implementação, podes utilizar o modo em que o CageFS está, por princípio, desativado e as contas individuais são ativadas; em alternativa, existe um modo em que o CageFS está, por princípio, ativado, com exceções.

Os seguintes comandos de leitura destinam-se a administradores autorizados num sistema com o CageFS instalado. TESTBENUTZER Substitua por uma conta existente e autorizada para o teste. Os direitos necessários e o resultado concreto dependem do sistema; os comandos não alteram nenhuma configuração.

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --display-user-mode
/usr/sbin/cagefsctl --user-status TESTBENUTZER

O primeiro comando mostra o estado global do CageFS, o segundo o Modo de funcionamento. O terceiro consulta o estado da conta selecionada. O modo e o estado da conta devem ser considerados em conjunto: um modo ativado por predefinição pode ter exceções, enquanto no outro modo as contas individuais são incluídas expressamente.

Uma mensagem de estado positiva não constitui, por si só, prova de que todos os serviços estejam efetivamente a funcionar no contexto previsto. Por isso, documente separadamente o que a administração comunica e quais os percursos de execução que foram verificados com a conta de teste. Só depois disso é que se pode decidir se o projeto-piloto pode ser alargado a outras contas e quais as exceções necessárias do ponto de vista operacional.

Comparação de abordagens de proteção

As abordagens diferem sobretudo no que diz respeito aos limites que estabelecem e a quem os gere. A tabela classifica os seus objetivos de proteção; os dados relativos aos custos operacionais são orientações qualitativas de planeamento, não valores medidos. Os requisitos concretos dependem da respetiva plataforma e da sua configuração.

As permissões de ficheiros e uma visibilidade restrita não são conceitos intercambiáveis: mesmo um caminho visível pode não ser legível, e um caminho disponibilizado deve ser devidamente protegido. O CageFS complementa estes direitos através de um ambiente estruturado. O LVE, por sua vez, aborda o consumo de recursos; para uma utilização conjunta, ambas as camadas têm de ser devidamente configuradas.

A máquina virtual própria desloca a fronteira administrativa em relação a um ambiente específico do utilizador: o sistema convidado tem de ser gerido pelo próprio utilizador e continua a depender da plataforma de virtualização. Um servidor separado altera novamente a infraestrutura partilhada. A variante mais adequada depende do modelo de ameaças, dos direitos necessários e dos recursos operacionais disponíveis.

Uma classificação geral de segurança seria, por isso, enganadora. Para comparar outros mecanismos e as respetivas áreas de aplicação, é útil a visão geral sobre Isolamento de processos no alojamento. O que é decisivo, em seguida, é a análise concreta: que limite deve impedir que tipo de acesso, que serviços o ultrapassam e quem supervisiona a configuração?

Testar os percursos de execução de forma controlada

O facto de uma conta estar ativada não significa necessariamente que todos os processos associados sejam efetivamente iniciados no CageFS. O que é determinante é o respetivo Caminho de execução: O início de sessão via SSH, o servidor Web e as tarefas agendadas podem utilizar diferentes integrações. Por isso, os administradores devem verificar, para cada serviço relevante, como este atribui os processos à conta e ao seu ambiente.

Para um teste controlado, o operador cria uma conta de teste autorizada e utiliza exclusivamente ficheiros de teste próprios e expressamente aprovados. Um ficheiro dentro do ambiente previsto pode indicar se o acesso esperado funciona; um ficheiro preparado separadamente, fora da vista prevista, serve para verificar a delimitação. Os diretórios de clientes externos não constituem material de teste adequado para este fim.

Verifique primeiro, através do SSH, qual é o ambiente em que a conta de teste está efetivamente a funcionar e se os ficheiros de teste previstos estão acessíveis conforme esperado. Repita a verificação com uma aplicação web configurada para o efeito e uma tarefa agendada. Os resultados podem variar se os serviços estiverem integrados de forma diferente ou se estiverem a ser executados num contexto de utilizador diferente.

Regista o serviço, a conta, o caminho e o resultado de cada tentativa. Um acesso recusado apenas comprova a limitação observada neste contexto específico; não prova nem o isolamento correto de todos os serviços nem a segurança de todo o anfitrião. Por outro lado, um acesso inesperadamente bem-sucedido deve ser investigado antes de se colocarem mais contas em funcionamento.

Como cliente de alojamento, podes verificar o teu próprio contexto de execução e os ficheiros partilhados. Normalmente, não podes verificar de forma independente as definições globais do CageFS, outras contas e a integração de todos os serviços. Essas questões são da responsabilidade do operador; caso detete alguma anomalia, descreve-lhe o serviço em causa e o caminho específico.

Falta de ferramentas e manutenção do Skeleton

Se uma ferramenta estiver instalada no anfitrião, mas não for possível encontrá-la na conta do cliente, verifica primeiro o contexto de execução. Uma chamada via SSH não tem necessariamente de utilizar o mesmo ambiente que uma aplicação web ou uma tarefa agendada. Verifica, em seguida, o caminho de pesquisa e a mensagem de erro específica, antes de presumires que falta um pacote.

Em seguida, o operador analisa o Esqueleto e a configuração do mount. O esqueleto ajuda a determinar quais os ficheiros e diretórios que serão disponibilizados no CageFS. Assim, um programa pode estar presente no anfitrião e, mesmo assim, não estar disponível no ambiente específico do utilizador; as bibliotecas necessárias e outras dependências também têm de ser tidas em conta na disponibilização.

A solução prática não consiste em integrar, por precaução, diretórios de host de grande dimensão. Isso poderia tornar visíveis mais ficheiros do que o necessário para a tarefa. Em vez disso, o administrador deve selecionar os ficheiros de programa e as dependências necessárias com base na documentação do fabricante e, em seguida, verificar, no contexto de serviço previsto, se a ferramenta funciona.

Para Manutenção do Skeleton É também necessário ter em conta as alterações nos pacotes do sistema e no Painel de Controlo. O CloudLinux documenta uma atualização periódica; após determinadas alterações, pode ser necessária uma atualização forçada. Esta também pode ser necessária após uma reconstrução do Apache. Isso não significa, contudo, que seja necessário executar o mesmo comando manual após cada atualização.

Planeie a atualização de acordo com a plataforma utilizada e, em seguida, verifique as aplicações e ferramentas afetadas. Se uma aplicação funcionava anteriormente e deixa de funcionar após uma alteração, a data da alteração do pacote, o serviço afetado e a mensagem de erro exata ajudam a identificar o problema. Desta forma, é possível distinguir entre um problema de implementação e uma falha da aplicação.

Operar com segurança e tomar decisões de forma consciente

Para a decisão operacional, não basta saber apenas se o CageFS está, em princípio, disponível. O operador tem de saber quais as contas e os serviços que devem ser protegidos, quais os programas necessários para tal e quem é responsável pela integração e manutenção. A visibilidade limitada do sistema de ficheiros complementa outras medidas de segurança; não substitui nem as aplicações seguras nem a proteção dos dados de acesso.

Merecem especial atenção áreas comuns e montagens adicionais. O CloudLinux descreve, para /dev/shm uma integração comum e uma opção de isolamento por utilizador. É necessário verificar, com base na configuração concreta, qual a variante que se aplica efetivamente. As montagens adicionais devem fornecer apenas o que as aplicações necessitam, uma vez que podem alargar o ambiente visível.

Um erro ao entrar no CageFS também tem implicações de segurança. A partir da versão CageFS 7.2.0-1, a CloudLinux documenta uma opção que permite impedir a execução de processos no caso de um erro deste tipo. Verifica a versão instalada e a configuração efetiva, em vez de deduzir o comportamento desta opção num serviço de alojamento específico com base apenas na sua existência.

As alterações ao Skeleton, às montarias ou à atribuição de contas devem ser incluídas num Procedimentos de manutenção. Nesse contexto, tenha em conta possíveis remontagens, as aplicações afetadas e uma janela de manutenção; documente também como a alteração pode ser revertida em caso de problemas. Posteriormente, os percursos de execução relevantes e as ferramentas necessárias devem ser novamente verificados com as contas de teste previstas.

Para os clientes, a questão decisiva é saber que tipo de separação o fornecedor efetivamente implementa e como a verifica. Os operadores, por seu lado, têm de ponderar em conjunto as necessidades de proteção e o esforço contínuo envolvido: um ambiente demasiado generoso pode enfraquecer a delimitação, enquanto um ambiente demasiado restrito pode prejudicar as aplicações necessárias. Ambas as situações exigem uma configuração consciente e uma verificação regular.