Capítulo 13. Segurança

13.1. O que é uma caixa de areia (sandbox)?
13.2. O que é securelevel?
13.3. O que é essa conta UID 0 toor? Eu fui comprometido?

13.1.

O que é uma caixa de areia (sandbox)?

Sandbox é um termo de segurança. Isso pode significar duas coisas:

  • Um processo que é colocado dentro de um conjunto de paredes virtuais que são projetadas para impedir que alguém que interrompa o processo seja capaz de invadir o sistema mais amplo.

    O processo só é capaz de correr dentro das barreiras. Desde que nada que o processo faça em relação à execução de código seja capaz de violar as barreiras, uma auditoria detalhada de seu código não é necessária para poder dizer certas coisas sobre sua segurança.

    As barreiras podem ser um ID do usuário, por exemplo. Esta é a definição usada nas páginas de manual de security(7) e named(8).

    Veja o serviço ntalk, por exemplo (veja inetd(8)). Este serviço costumava rodar como ID de usuário root. Agora ele é executado como ID do usuário tty. O usuário tty é um sandbox projetado para tornar mais difícil para alguém que invadiu o sistema com sucesso através do ntalk ser capaz de hackear além do seu ID de usuário.

  • Um processo que é colocado dentro de uma simulação da máquina. Isso significa que alguém que é capaz de entrar no processo pode acreditar que ele pode invadir a máquina mais ampla, mas está, na verdade, apenas invadindo uma simulação dessa máquina e não modificando nenhum dado real.

    A maneira mais comum de fazer isso é construir um ambiente simulado em um subdiretório e então executar os processos nesse diretório chrooted para que o diretório / para esse processo seja este, não o diretório / real do sistema).

    Outro uso comum é montar um sistema de arquivos subjacente somente leitura e, em seguida, criar uma camada do sistema de arquivos sobre ele, o que dá a um processo uma visualização aparentemente gravável nesse sistema de arquivos. O processo pode acreditar que é capaz de escrever nesses arquivos, mas o processo apenas vê os efeitos - outros processos no sistema não, necessariamente.

    Foi feita uma tentativa de tornar esse tipo de sandbox tão transparente que o usuário (ou hacker) não percebe que está dentro dele.

O UNIX® implementa dois sandboxes principais. Um está no nível do processo e o outro está no nível do usuário.

Todo processo UNIX® é completamente protegido contra qualquer outro processo UNIX®. Um processo não pode modificar o espaço de endereço de outro.

Um processo UNIX® é de propriedade de um determinado ID de usuário. Se o ID de usuário não for o usuário root, ele servirá para proteger o processo contra processos pertencentes a outros usuários. O ID do usuário também é usado para proteger os dados no disco.

13.2.

O que é securelevel?

securelevel é um mecanismo de segurança implementado no kernel. Quando o nível de segurança é positivo, o kernel restringe certas tarefas; nem mesmo o superusuário (root) pode executá-los. O mecanismo de securelevel limita a capacidade de:

  • Desativar determinados flags de arquivo, tais como schg (o flag de sistema imutável).

  • Escrever na memória do kernel através de /dev/mem e /dev/kmem.

  • Carregar módulos do kernel.

  • Alterar as regras do firewall.

Para verificar o status do securelevel em um sistema em execução:

# sysctl -n kern.securelevel

A saída contém o valor atual do nível de segurança. Se for maior que 0, pelo menos algumas das proteções do securelevel são ativadas.

O securelevel de um sistema em execução não pode ser reduzido, pois isso invalidaria seu propósito. Se uma tarefa exigir que o securelevel seja não-positivo, altere as variáveis ​​kern_securelevel e kern_securelevel_enable em /etc/rc.conf e reinicialize.

Para obter mais informações sobre o securelevel e as coisas específicas que todos os níveis fazem, consulte init(8).

Atenção:

O securelevel não é uma bala de prata; tem muitas deficiências conhecidas. Mais frequentemente do que não, fornece uma falsa sensação de segurança.

Um dos seus maiores problemas é que, para que seja eficaz, todos os arquivos usados ​​no processo de inicialização até que o nível de segurança seja definido devem ser protegidos. Se um invasor puder fazer o sistema executar seu código antes do nível de segurança que está sendo definido (o que acontece muito tarde no processo de inicialização, pois algumas coisas que o sistema deve fazer na inicialização não podem ser feitas em um nível elevado), suas proteções são invalidadas . Embora essa tarefa de proteger todos os arquivos usados ​​no processo de inicialização não seja tecnicamente impossível, se for obtida, a manutenção do sistema se tornará um pesadelo, já que seria necessário desativar o sistema, pelo menos no modo de usuário único, para modificar um arquivo de configuração.

Este ponto e outros são frequentemente discutidos nas listas de discussão, particularmente na lista de discussão de segurança do FreeBSD. Pesquise nos arquivos aqui para uma discussão extensa. Um mecanismo mais refinado é o preferido.

13.3.

O que é essa conta UID 0 toor? Eu fui comprometido?

Não se preocupe. toor é uma conta de superusuário alternativa, onde toor é root soletrada para ao contrário. Ele deve ser usado com um shell não padrão, portanto, o shell padrão para root não precisa ser alterado. Isto é importante porque os shells que não fazem parte da distribuição base, mas que são instalados a partir de ports ou packages, são instalados em /usr/local/bin que, por padrão, reside em um sistema de arquivos diferente . Se o shell do root estiver localizado em /usr/local/bin e o sistema de arquivos contendo /usr/local/bin) não está montado, root não poderá efetuar login para corrigir um problema e terá que reinicializar no modo de usuário único para inserir o caminho para um shell.

Algumas pessoas usam toor para tarefas do dia-a-dia do root com um shell não padrão, deixando o root, com um shell padrão, para o modo de usuário único ou emergências. Por padrão, um usuário não pode logar usando toor porque ele não tem uma senha, então efetue login como root e defina um senha para toor antes de usá-lo para efetuar login.

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.