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
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:
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
Error: No site found with the domain 's2.dicas-l.com.br' (Learn more)