… para os sistemas baseados em GNU/Linux (e Unix)? Há muitos anos, quando fiz um treinamento designado para obter a certificação Red Hat Enterprise Linux, tive o meu primeiro contato o SELinux e as experiências, não foram as melhores. Este por sua vez, é um módulo de segurança embutido no kernel, que promove um mecanismo de controle de acesso mandatório (MAC), com o objetivo de definir quais processos e/ou serviços poderão acessar os recursos do sistema, que por sua vez podem ser arquivos & diretórios, soquetes, portas, etc.
Apesar de ser uma tecnologia poderosa e dotada de uma incrível flexibilidade, o SELinux possui uma curva de aprendizado considerável e por isto, se tornou complexo para dominar e gerenciar! Na época, não consegui obter a aprovação para o exame RHCE, justamente em vista das dificuldades que tive em lidar com ele. Apesar disto, o SELinux também me possibilitou realizar algumas reflexões em relação a administração de sistemas e dentre as conclusões que tive, a principal estava em abraçar (bem forte) as tecnologias e os serviços que promovem a simplicidade e facilidade de uso, além de serem práticas e eficientes!
Então, conheci o AppArmor (entre outros que por ora, não vou entrar em maiores detalhes). Embora tenha sido concebido para prover os mesmos recursos que o SELinux (e ter surgido praticamente na mesma época), o AppArmor se destaca pela sua menor curva de aprendizado e difere-se por utilizar o caminho (path) como base para a implementação do controle de acesso baseado em perfil (o SELinux é baseado em atributos). Enquanto que o SELinux é geralmente usado por distros “red-likes”, o AppArmor é mais voltado para as distros baseadas no Debian.
Embora seja menos flexível e versátil, o AppArmor também trouxe uma outra vantagem importante para os administradores de sistemas: a maior rapidez para prover as soluções necessárias e assim, garantir o seu perfeito funcionamento! No entanto, se determinados recursos tiverem caminhos diferentes para o acesso (“graças” ao uso de hardlinks), isto pode levar a um estado de inconsistência e afetar o bom funcionamento do mecanismo deste segurança. Em suma: ganha-se na simplicidade e facilidade, perde-se na flexibilidade e eficiência!
Eis, a questão: qual é o “melhor” mecanismo de segurança? Se não bastasse as diferentes respostas em virtude do ponto de vista dos administradores e suas preferências, ainda teremos que levar em conta a existência de outros projetos interessantes “correndo por fora”, como é o caso do Tomoyo, do Smack e do Yama! E cada um deles também apresentará as suas vantagens e desvantagens, embora não sejam tão populares quanto o SELinux e o AppArmor. E para variar, cada um terá a sua curva de aprendizado, além dos desafios para a sua gestão e administração.
Ao menos, alternativas é que não faltam no universo do Software Livre… &;-D