Segurança extrema com LIDS: novos recursos
Quem leu o primeiro artigo sobre LIDS que postei aqui não deve perder esta segunda parte, onde são tratados os novos recursos de sua versão 1.2 e apresentadas as evoluções desse formidável sistema.
Parte 3: Trusted Path - Trusted ACL - Regras
Para melhorar a proteção que o LIDS oferece a nossa máquina, o TPE foi
dividido em 3 componentes e veremos eles abaixo:
Não é muito usual devido que, para que o diretório seja protegido, deve ser do root e do grupo dele, já que a verdadeira função e essência do LIDS é proteger o sistema e tirar do usuário root o poder absoluto. Então as melhores opções que temos para proteger determinados diretórios é a proteção mínima de marcá-los como READONLY. Vamos ver alguns exemplos logo abaixo:
# lidsconf -A -o /sbin -j READONLY
Executáveis abaixo do /sbin estão como "Trusted".
# lidsconf -A -o /lib -j READONLY
Libraries abaixo do /lib estão como "Trusted".
# lidsconf -A -o /lib/modules -j READONLY
Módulos abaixo do /lib/modules estão como "trusted".
# lidsconf -A -o /var/workdir -j READONLY
# lidsconf -A -o /sbin/application_a -j READONLY
# lidsconf -A -s /sbin/application_a -o /var/workdir -j WRITE
Como application_a está protegido como READONLY e tem permissão de WRITE em workdir, então arquivos que estão dentro do /var/workdir serão considerados confiáveis.
Não é muito interessante do ponto de vista que teremos que definir quais binários podem ser executados e tudo mais no sistema. O foco do LIDS está mais voltado para os binários/programas do que os usuários que irão executá-los, isso já pode ser considerado nosso LIDS ACL :)
Podemos definir uma regra básica que nos tiraria muitas dores de cabeça, como por exemplo: somente binários confiáveis podem rodar e apenas libraries e módulos confiáveis podem ser carregados no sistema.
Mataríamos possibilidades múltiplas de comprometimento :)
Mas vamos parar para pensar um momento, se formos realmente analisar o conceito do TPE veremos que ele já existe na versão current do LIDS. Quando nós setamos CONFIG_LIDS_NO_EXEC_UP como Y na hora da instalação do kernel com o LIDS, ele não irá executar programas depois que o kernel for selado (lidsadm -I). O que foi feito é apenas uma pequena melhoria no código para que possamos fazer isso antes de selar a kernel e que certos arquivos sejam executados mesmo com o kernel selado.
Trusted Path
Não é muito usual devido que, para que o diretório seja protegido, deve ser do root e do grupo dele, já que a verdadeira função e essência do LIDS é proteger o sistema e tirar do usuário root o poder absoluto. Então as melhores opções que temos para proteger determinados diretórios é a proteção mínima de marcá-los como READONLY. Vamos ver alguns exemplos logo abaixo:
# lidsconf -A -o /sbin -j READONLY
Executáveis abaixo do /sbin estão como "Trusted".
# lidsconf -A -o /lib -j READONLY
Libraries abaixo do /lib estão como "Trusted".
# lidsconf -A -o /lib/modules -j READONLY
Módulos abaixo do /lib/modules estão como "trusted".
# lidsconf -A -o /var/workdir -j READONLY
# lidsconf -A -o /sbin/application_a -j READONLY
# lidsconf -A -s /sbin/application_a -o /var/workdir -j WRITE
Como application_a está protegido como READONLY e tem permissão de WRITE em workdir, então arquivos que estão dentro do /var/workdir serão considerados confiáveis.
Trusted ACLs
Não é muito interessante do ponto de vista que teremos que definir quais binários podem ser executados e tudo mais no sistema. O foco do LIDS está mais voltado para os binários/programas do que os usuários que irão executá-los, isso já pode ser considerado nosso LIDS ACL :)
Regras
Podemos definir uma regra básica que nos tiraria muitas dores de cabeça, como por exemplo: somente binários confiáveis podem rodar e apenas libraries e módulos confiáveis podem ser carregados no sistema.
Mataríamos possibilidades múltiplas de comprometimento :)
Mas vamos parar para pensar um momento, se formos realmente analisar o conceito do TPE veremos que ele já existe na versão current do LIDS. Quando nós setamos CONFIG_LIDS_NO_EXEC_UP como Y na hora da instalação do kernel com o LIDS, ele não irá executar programas depois que o kernel for selado (lidsadm -I). O que foi feito é apenas uma pequena melhoria no código para que possamos fazer isso antes de selar a kernel e que certos arquivos sejam executados mesmo com o kernel selado.
estou pensando em postar um bom sobre snort.