Introdução aos Níveis de Segurança do Kernel do FreeBSD
=======================================================
Colaboração: Giancarlo Rubio
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=
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=
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/handbook)
- http://doc.fug.com.br (http://doc.fug.com.br)
- http://www.freebsd.org/doc/en_US.ISO885 ... urity.html (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/security.html)
- http://www.freebsd.org/doc/en_US.ISO885 ... stall.html (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-install.html)
- http://www.freebsd.org/doc/en_US.ISO885 ... k/mac.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
Ótimo texto. Apesar de não usar BSD's, o texto está ótimo.
Valeu pelo esforço.
HadeS