Política MLS

Durante o desenvolvimento do Linux Fedora Core 5/Red Hat Enterprise Linux 5, foi desenvolvida a política de segurança MLS, ou Multilevel Security (Segurança Multi-nível, em português). A política MLS é similar a política strict, mas adiciona um campo nos contextos de segurança para separar níveis. O SELinux pode usar estes níveis para separar dados em um ambiente que necessite de uma separação rígida hierarquicamente. O exemplo mais comum desse tipo de classificação é o no uso militar, onde os dados são classificados em determinados níveis.

Muitas organizações comerciais precisam proteger informações, e a maioria têm algum grau de tolerância para vazamento parcial ou total dessa informação. Organizações que usam sistemas MLS não toleram nenhum tipo de vazamento. O valor da informação que se deseja proteger define o limite de dinheiro que as organizações irão investir em confidencialidade de dados [SMITH 2007]. Caso o vazamento da informação ocorra, as principais consequências são perda de negócios e até mesmo o fechamento de empresas. As agências de defesa, que incluem serviços militares, organizações de inteligência, agências relacionadas a governos, não conseguem se recuperar facilmente de alguns tipos de vazamentos de informações. Esses tipos de falhas não podem ser facilmente corrigidos somente gastando mais dinheiro, como no primeiro caso. Durante a Guerra Fria, a ameaça das armas nucleares de aniquilação em massa levou a políticos e militares se preocuparem muito seriamente sobre esse tipo de riscos de vazamento de informações secretas, levando as agências de defesa demandar sobre níveis de segurança de dados muito antes das organizações comerciais precisarem.

O termo multinível é usado porque as agências de defesa classificaram pessoas e informações em diferentes níveis de confiança e sensibilidade. Esses níveis representam as classificações de segurança bem conhecidas: confidencial, secreto, e ultra secreto (confidential, secret e top secret). Pessoas que possuem o grau confidencial são autorizados a ver documentos confidenciais, mas não são autorizadas a ver documentos secretos ou ultra secretos. Esses níveis formam uma hierarquia simples demonstrada graficamente na figura 3.2, que ilustra a única direção que os dados devem fluir:

Figure Figura 3.2:: Hierarquia dos Níveis de Segurança

No modelo de segurança MLS, sujeitos e objetos são rotulados com níveis de segurança (SLs - Security Levels). Um nível de segurança é composto de dois tipos de entidades:

• Sensibilidade: um atributo hierárquico como ``confidencial'', ``secreto'' ou ``ultra secreto''. Pode assumir valores de s0 até s15 (16 níveis hierárquicos de segurança).
• Categorias: um conjunto de atributos não hierárquicos como ``US only'' ou ``UFO''. Pode assumir valores de c0 até c1023 (1024 categorias de segurança).

Um SL (nível de segurança) possui uma sensibilidade, e pode ter nenhuma ou várias categorias. SLs em objetos são chamados classificações e SLs em sujeitos são chamados autorização. Basicamente o que o modelo de segurança MLS realiza são questões do tipo: ``Um processo rodando com a autorização Ultra Secreto / UFO pode escrever em um arquivo classificado como Ultra Secreto / UFO ?'' A política implementada do tipo MLS irá responder a esse tipo de questão.

Os nomes das categorias e níveis de sensibilidade são configuradas pelo administrador através do arquivo de configuração /etc/selinux/mls/setrans.conf. Internamente o SELinux enxerga os níveis de sensibilidade apenas como os valores de s0 até s15 e categorias de c0 até c1023. A intenção aqui é habilitar a flexibilidade máxima quando sistemas estão sendo implantados e manter compatibilidade.

Outro conceito importante na política MLS utilizada pelo SELinux é a VFS Polyinstantiation (Múltiplas instâncias de Sistemas de Arquivos Virtuais). Muitos programas legados simplesmente não funcionando usando MLS sem polyinstantiation porque eles esperam sempre ter autorização para escrever em diretórios como /tmp, $HOME, o que é negado pelo uso de MLS. Para contornar esse problema, são criados múltiplos sistemas de arquivos virtuais com esses diretórios problemáticos para cada programa legado, permitindo assim o seu funcionamento e isolamento total das outras aplicações.

O objetivo da implantação da política MLS no SELinux é permitir o sistema operacional Linux ser certificado EAL4+/LSPP (Evaluation Assurance Level superior ao nível 4/Labeled Security Protection Profile). O Linux foi o primeiro sistema operacional que combinou o modelo Bell e LaPadula [BELL 1975] e tipo aplicado (Type Enforcement). A certificação LSPP é equivalente à antiga classificação B1 da TC SEC [NSA 2007:1] enquanto a equivalência da certificação EAL 4 ou superior pode ser visualizada de uma forma aproximada a outros métodos de classificação na tabela 3.1 [SMITH 2000]:

Table Tabela 3.1:: Equivalências entre níveis de certificação

TC SEC	D	-	C1	C2	B1	B2	B3	A1
IT SEC	E0	-	E1	E2	E3	E4	E5	E6
Common Criteria	-	EAL1	EAL2	EAL3	EAL4	EAL5	EAL6	EAL7

• TC SEC: Trusted Computer System Evaluation Criteria é uma norma do Departamento de Defesa dos Estados Unidos (DoD) que estabelece requisitos básicos para avaliar a eficácia dos controles de segurança de um sistema computacional. Também chamado de Orange Book [NSA 1985];
• IT SEC: Information Technology Security Evaluation Criteria é uma norma criada em 1990 pelos países da França, Holanda, Inglaterra e Alemanha que define os requisitos dos controles de segurança de um sistema;
• Common Criteria: Common Criteria for Information Technology Security Evaluation é uma norma internacional padronizada (ISO/IEC 15408) para segurança de sistemas. Veio em substituição ao TC SEC [ISO 2005].

Para uma distribuição Linux possuir a certificação EAL4, ela deve ser projetada metodicamente, testada e revisada. Para isso foram desenvolvidos conjuntos de testes, como o LTP (Linux Test Project) [LTP 2007] que ajuda a verificar se uma distribuição Linux pode ser submetida à avaliação de um laboratório de testes para efetuar a certificação. Sistemas operacionais comerciais que provêem recursos de segurança baseado em usuário são tipicamente avaliados em EAL4. Exemplos de sistemas avaliados são: Novell NetWare, SUSE Linux Enterprise Server 9, Windows 2000 Service Pack 3 and Red Hat Enterprise Linux 5 [CCEVS 2007].

Figure Figura 3.3:: Datas das Certificações Common Criteria para RHEL e Suse

Uma observação importante é que não necessariamente um sistema utilizando MLS seja mais seguro que outro que não o utilize. O MLS tem como objetivo garantir a confidencialidade e é totalmente dependente da política de segurança para garantir essa característica, enquanto as políticas strict e targeted têm o objetivo de garantir a integridade. Por ser uma política de segurança muito complexa e especializada, não é muito utilizada de maneira geral.

Existe ainda um subconjunto do MLS chamado MCS - Multi-Category Security (Segurança de Múltiplas Categorias, em português). Objetivo da política MCS é adaptar a política MLS para uso mais genérico. As diferenças entre as duas políticas são:

• O nível de sensibilidade não é utilizado, desaparecendo aqui o conceito de múltiplos níveis de segurança (sempre será s0). Geralmente designações hierárquicas de segurança não são muito aplicáveis fora do mundo militar ou ambientes similares, onde são rigidamente definidos e controlados.

• Somente o campo categoria do SL é utilizado (c0..c1023). Categorias podem ser nomes de departamentos, como ``Financeiro'' e ``Recursos Humanos''. Elas devem expressar a natureza da informação e serem associadas com regras de negócio para manuseio de informações.

• O MCS descarta o modelo de segurança Bell La-Padula (BLP). Propriedades BLP como ``Não-Escrever-Abaixo'', a qual é designada para previnir vazamento de níveis de segurança altos para níveis de segurança baixos (figura 3.2), pois são na maioria das vezes confusos e podem não permitir o uso de alguns softwares. Por exemplo, considerar que o root não consiga escrever no diretório /tmp é um dos possíveis problemas relacionados a compartilhamento de dados e o uso de MLS.

• MCS é discricionário, similar à lógica DAC do Unix. A implementação corrente permite usuários com controles MCS sobre os seus próprios arquivos. Administradores decidem em quais categorias os usuários estão, e usuários podem adicionar ou remover objetos que possuem, em qualquer categoria que estejam inseridos. É possível configurar o MCS para fazê-lo menos discricionário, mas nesse caso é para isso que o MLS foi feito.

• Para acessar um objeto, as categorias em que o usuário está deverão ser as mesmas, ou um (adequado) superconjunto das categorias do objeto.

• MCS usa a tecnologia MLS, mas não é MLS. MCS não provê nenhuma proteção herdada da política MLS contra softwares maliciosos ou vulneráveis, erros de usuário ou usuários mal intencionados; No entanto DAC e TE são validados primeiro e se o acesso for negado as regras MCS não serão avaliadas.