Gentoo Hardened vs outras distros

Está tudo no código-fonte! Gentoo hardened é uma distro voltada para segurança, o perfil realmente reforçado embala muito para torná-lo realmente seguro.

Mas vale a pena compilar? Uma grande questão entre os fóruns do Linux.

Vamos dar uma olhada no perfil reforçado do Gentoo em termos de segurança:

enquanto adiciona algum secu ridade é tão pouco que não vale a pena na maioria dos casos. Ele fornece mais segurança em uma distro binária porque todos têm os mesmos binários e um invasor não precisa adivinhar onde uma parte específica do código pode ser carregada, mas ao executar uma distribuição de origem, seu espaço de endereço já é bastante único. O único caso em que fornece alguma segurança quando um invasor está tentando adivinhar um endereço para uma exploração, adivinhar incorretamente provavelmente travará o processo e será recarregado em um novo endereço. Você tem dados valiosos o suficiente para um invasor passar por isso? incômodo para obtê-lo? Se você fizer isso, deverá usar um perfil reforçado, mas a segurança física e a criptografia de disco são mais importantes porque, se valer tanto assim, será mais fácil simplesmente roubá-lo.

Esteja ciente de que não há perfil de desktop protegido, então isso por si só tornará um pouco mais difícil se planejar usá-lo em um desktop.

Outra razão é se você deseja usar algo como o SELinux (que não requer um perfil reforçado), que fornece um controle muito refinado sobre o controle de acesso, mas também é muito restritivo. Acho que só vale a pena para grandes redes com muitos usuários e diferentes níveis de acesso a dados confidenciais.

Eu precisava de alguns dos recursos do SELinux, mas me conformei em usar o AppArmor de uma maneira incomum para realizá-los porque o SELinux é muito problemático. Tudo o que o AppArmor realmente faz é fornecer isolamento de processos ou sandbox. Se um invasor obtiver acesso por meio de um exploint, ele só poderá acessar os arquivos aos quais o serviço explorado tem acesso. Eu o uso com um perfil catch all que impede a execução de todos os diretórios pessoais e graváveis mundiais, e acesso a chaves ssh / pgp, chaveiros, etc. Isso funciona bem para servidores e desktops e não é muito restritivo. E se eu precisar executar código do meu diretório inicial para desenvolvimento, posso iniciar um shell irrestrito via sudo. Posso deixar meu laptop desbloqueado com a carteira aberta (eu uso o módulo kwallet pam) e será muito difícil para você conseguir qualquer coisa como chaves ssh ou senhas (também tenho patches para kwallet, então requer uma senha ord para mostrar senhas salvas), mas os programas que precisam delas têm acesso a elas.

Mas o que o torna mais rígido? vamos examinar alguns desses itens também:

• PaX é um patch do kernel que nos protege de estouros de pilha e heap. PaX faz isso usando ASLR (randomização de layout de espaço de endereço), que usa localizações de memória aleatórias na memória. Cada shellcode deve usar um endereço para saltar para embutido nele a fim de obter a execução do código e, como o endereço do buffer na memória é aleatório, isso é muito mais difícil de conseguir. PaX adiciona uma camada adicional de proteção, mantendo os dados usados pelo programa em uma região de memória não executável, o que significa que um invasor não será capaz de executar o código que conseguiu gravar na memória. Para usar PaX, temos que usar um kernel habilitado para PaX, como hardened-sources.
• PIE / PIC (código independente de posição): Normalmente, um executável tem um endereço base fixo onde eles são carregados. Este também é o endereço que é adicionado aos RVAs para calcular o endereço das funções dentro do executável. Se o executável for compilado com suporte PIE, ele pode ser carregado em qualquer lugar da memória, enquanto deve ser carregado em um endereço fixo se compilado sem suporte PIE. O PIE precisa ser habilitado se quisermos usar PaX para tirar proveito do ASLR.
• RELRO (relocação somente leitura): Quando executamos o executável, o programa carregado precisa escrever em algumas seções que não não precisa ser marcado como gravável depois que o aplicativo foi iniciado. Essas seções são .ctors, .dtors, .jcr, .dynamic e .got [4].Se marcarmos essas seções como somente leitura, um invasor não será capaz de usar certos ataques que podem ser usados ao tentar obter a execução de código, como sobrescrever entradas em uma tabela GOT.
• SSP ( protetor de esmagamento de pilha) é usado no modo de usuário; ele protege contra estouros de pilha colocando um canário na pilha. Quando um invasor deseja estourar o endereço EIP de retorno na pilha, ele também deve estourar o canário escolhido aleatoriamente. Quando isso acontece, o sistema pode detectar que o canário foi sobrescrito e, nesse caso, o aplicativo é encerrado, não permitindo que um invasor vá para um local arbitrário na memória e execute o código a partir daí.
• RBAC (controle de acesso baseado em função): Observe que RBAC não é o mesmo que RSBAC, que apresentaremos mais tarde. O RBAC é um controle de acesso que pode ser usado pelo SELinux, Grsecurity, etc. Por padrão, o criador de um arquivo tem controle total sobre o arquivo, enquanto o RBAC força o usuário root a ter o controle do arquivo, independente de quem o criou isto. Portanto, todos os usuários do sistema devem seguir as regras RBAC definidas pelo administrador do sistema.

Além disso, também podemos usar os seguintes sistemas de controle de acesso, que são usados para controlar o acesso entre processos e objetos. Normalmente, temos que escolher um dos sistemas descritos abaixo, porque apenas um dos sistemas de controle de acesso pode ser usado por vez. Os sistemas de controle de acesso incluem o seguinte:

• SELinux (Linux com segurança aprimorada)
• AppArmor (armadura de aplicativo)
• Grsecurity, que contém vários patches que pode ser aplicado ao kernel para aumentar a segurança de todo o sistema. Se quisermos habilitar Grsecurity no kernel, devemos usar um kernel habilitado para Grsecurity, que é hardened-sources.
• RSBAC (controle de acesso baseado em conjunto de regras): Devemos usar kernel rsbac-sources para construir um kernel com suporte a rsbac.

Tudo se resume à grande questão, conforme declarado anteriormente? Vale a pena compilar? Realmente se resume a como ou o que você está protegendo e vale a pena o esforço? Ou você será capaz de realmente proteger o que não quer que olhos curiosos vejam?

Comentários

• Ok, obrigado pelo esclarecimento de todos essas tecnologias de aplicação de segurança. Portanto, se entendi seu ponto, esses itens são muito úteis para melhorar a segurança de um sistema; mas você pergunta " se vale a pena compilar? ". Então, por que eles não são habilitados por padrão em algumas das principais distros? Eu li que PaX em um desktop pode quebrar alguns binários (ouvi falar de java ou firefox); é a única razão?
• A razão pela qual PaX e grsecurity não são o padrão em muitas distros é devido à política e egos. Os desenvolvedores de ambos têm personalidades que conflitam fortemente com a equipe de desenvolvimento do kernel do Linux. Além disso, eles não desejam perder tempo dividindo seu patch em pedaços que seriam aceitos no upstream e, em vez disso, usam seu tempo para desenvolver mais recursos de segurança.
• Observe também que grsecurity é não um sistema de controle de acesso. Spender (criador do grsecurity) fica muito irritado quando as pessoas o chamam de sistema de controle de acesso e o comparam com o SELinux. : P Grsecurity é uma combinação de patches de kernel que aumenta a segurança do kernel eliminando classes de bug. O sistema de controle de acesso RBAC que possui é irrelevante em comparação com o resto. Os recursos de segurança do Grsecurity ' são tão extensos que ocupariam muito mais espaço do que poderia ser colocado em uma única postagem. Verifique grsecurity.net para ver uma lista bastante abrangente.
• enquanto adiciona alguma segurança, ' é tão pouco que ' não vale a pena na maioria dos casos – Uh, isso é totalmente incorreto. E a segurança realmente não tem nada a ver com esconder endereços. Eu ' estou surpreso que esta resposta tenha recebido votos positivos.