De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.

Introdução aos Níveis de Segurança do Kernel do FreeBSD

Colaboração: Giancarlo Rubio

Data de Publicação: 11 de Julho de 2006

Há alguns dias na lista de discussão sobre FreeBSD da FUG-BR houve uma conversa sobre algumas questões de segurança, e comparações de modo de trabalho entre FreeBSD e OpenBSD. Uma das considerações era que no OpenBSD, suporte ao kernel tinha que ser estático, e que o sistema por segurança não permitia que módulos de kernel fossem carregados. Contudo, no FreeBSD esse comportamento também pode ser adicionado, apenas não é padrão. Trata-se de uma prerogativa do administrador de sistemas. A diferença é que o OpenBSD trabalha com nível de segurança positivo por padrão. Algo que no FreeBSD e no NetBSD apenas depende da vontade explícita do sysadmin. Aproveitei o encejo para escrever uma introdução sobre Níveis de Segurança do Kernel do FreeBSD, os chamados Kernel Securelevel , que você acompanha agora.

O kernel do FreeBSD pode rodar em até 5 níves de seguran'ca, onde o -1 é o mais baixo até o 3 que é o mais alto.

Por default esse valor é -1, conforme você pode ver com o comando abaixo:

  sysctl kern.securelevel
  kern.securelevel: -1

Vejamos cada um destes níveis

• 1: Modo default, sem segurança de kernel. A única segurança aqui é em relação à permissões tradicionais do de sistemas Unix.

• 0: Este nível é apenas usado quando o sistema está sendo inicializado pela primeira vez, e não possui alguma característica especial. Não há motivos especiais para utilizar este nível.

• 1: Aqui sim você realmente começa a ter segurança

• 1.1: Não é possivel carregar módulos ao kernel, a não ser que o mesmo seja recompilado. Veja:

    # sysctl kern.securelevel=1
    kern.securelevel: -1 -> 1
    # kldload if_tap
    kldload: can't load if_tap: Operation not permitted
  

• 1.2: Nenhum programa pode escerver diretamente a memória do sistema via /dev/mem ou /dev/kmem

• 1.3: Discos que foram montados não podem ser escritos diretamente, não sendo possível formatar partições ou usar o dd(1) nesses discos.

• 1.4: O Gerenciador de Janelas X não pode ser iniciado (pois ele faz acesso direto aos dispositivos de memória, e isso não é mais permitido nesse nível de segurança)

• 2: As mesmas característacas do modo 1 alêm de:

• 2.1: Impossibilidade de escrever direto a sistema de arquivos montados ou desmontados (exceto pelo mount(2),). Impossibilita alterar a estrutura do sistema de arquivos, redefinir ou modificar opções de montagem e também formatar newfs(8) quando o sistema estiver em multi-user.

• 2.2: A hora somente poderá ser alterada de 1 em 1 segundo.

• 3: As mesmas caracteristicas do modo 2 além proibir aletrações das definições de regras de firewall, seja o firewall ipfw(8), pfctl(8) ou ipf(8), e também proibe modificações nas disciplinas alternativas de enfileiramento, com altq(4) ou dummynet(4).

Vamos colocar a mão na massa.

Para alterar o nível basta digitar no seu shell

  sysctl kern.securelevel=<nivel escolhido>
  Exemplo: sysctl kern.securelevel=1

Para fazer o mesmo rodar a partir da inicialização coloque no seu /etc/rc.conf

  kern_securelevel_enable="YES"
  kern_securelevel=<nivel escolhido>

Giancarlo Rubio, PUC-PR, FUG-BR

Notas da Redação do Fug:

• A partir do nível de segurança positivo 1 (nível 1) as flags de arquivos imutáveis e apenas concatenação no nível do sistema (schg e sunlnk) não podem mais ser removidas, nem mesmo pelo root. As flags de arquivos imutáveis e apenas concatenação do nível do usuário (uchg e uunlnk) continuam sob total controle do proprietário do arquivo bem como do root, ao manipular estas flags com chflags(1). Isso complementa a segurança que pode ser imposta ao sistema com o uso de chflags(1), e também complementa o artigo escrito por Daniel Bristot sobre chflags.

• No FreeBSD a partir do nível de segurança 1 atributos extendidos do sistema de arquivo (apenas UFS2, portanto apenas disponível a partir do FreeBSD 5) de nível de sistema não podem mais ser modificados, nem pelo root. Já, de níveis de usuário continuam à mercê do proprietário do arquivo e do administrador (root). Máscaras máximas de privilégios para ACL (Access Control Lists - Listas de Controles de Acesso) não podem mais ser modificadas, nem pelo root. À critério do administrador de sistemas, ACLs podem ser armazenadas como atributos extendidos no nível do usuário ou no nível do sistema, exceto pela máscara que só é armazenada no nível de sistema. Se o administrador forçar que definições ACL sejam armazenadas como atributos extendidos do sistema de arquivos no nível do sistema, ACLs podem apenas ser adicionadas, mas não podem ser removidas nem editadas, à partir do nível de segurança 1.

• MAC, Mandatory Access Control, ou Controlde de Acesso imperativo, assim como ACLs, parte das implementações POSIX.1e no FreeBSD, à partir do nível de segurança 1 não podem mais ser alteradas. Apenas novas definições MAC podem ser adicionadas para cada módulo MAC (cada subsistema MAC tem função diferente), mas as já existentes não podem ser modificadas nem removidas, mesmo pelo super usuário. A partir do nível de segurança 2 qualquer label em arquivos, sistema de arquivos, interfaces de rede, trecho de memória ou porta de rede, bem como label associada à usuários, não podem mais ser editados, removidos, nem adicionados, nem mesmo pelo super usuário (root).

• As definições de atribuição de labels via login.conf(5) não podem mais ser modificadas. Labels (ou marcações) são identificadores disponíveis em todos os níveis do sistema operacional para fazer distinção entre exceções e aplicações de quaisquer recursos de segurança documentados na especificação POSIX.1e implementada FreeBSD, e MAC usa intensamente labels.

• A partir do nível de segurança 1 classes geom(4) só podem ser manipuladas através de rotinas credenciadas pelo kernel (usadas pelas chamadas de sistemas das aplicações de userland que controlam cada classe), e nunca através de outros programas ainda que usem as mesmas chamadas de sistema. A partir do nível de segurança 2 providers do geom(4) só poderão ter suas estruturas modificadas pelo kernel, e apenas consumers geom(4) só poderão se associar à providers se ambos já existirem, ou à critério do kernel quando um provider previamente existente informa o kernel que algumas classes de consumers são esperadas.

• A partir do FreeBSD 7.0, nível de segurança maior que 0 evitará que regras auditorias de chamadas de sistemas, requisições de transofações ou I/O e alocação de recursos, com o suporte à audit(4) do POSIX.1e não poderão ser mais removidas ou modificadas, e à partir do nível de segurança 2 não poderão sequer ter novas regras de auditoria criada.

Para saber mais, comece pelas seguintes referências:

• http://doc.fug.com.br/handbook
• http://doc.fug.com.br
• http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/security.html
• http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-install.html
• http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html

Em um FreeBSD instalado, leia:

• man securelevel
• man 8 init
• man 7 security
• man 1 chflags
• man 3 acl
• man 4 mac
• man 9 mac
• man 9 extattr
• man 2 extattr

ps. O pessoal do fug, complementou meu texto, crédito a eles tbm