Como limitar o acesso à chave ssh privada usando as políticas do SELinux?

Question

Estou usando a distribuição do Fedora - com suas políticas pré-instaladas do SELinux. Quero limitar o acesso não seguro às minhas chaves privadas na pasta ~/.ssh - para evitar vazamentos por possíveis malwares, que podem ser executados na minha conta. Os kits de raiz estão fora de questão.

Atualização 1: Eu quero resolver um problema de empresa com usuários novatos do Fedora - sem tokens USB, etc. Eles podem usar uma senha muito fraca. Não haverá problema se apenas os programas root user e ssh client tiverem acesso a chaves privadas. Não há necessidade de o usuário humano ver a chave privada - eu não sei o motivo de olhar para a chave privada, nem mesmo uma vez, para ninguém.

Como posso fazer isso? Sugira o uso do SELinux.

    

Answer 1

A maneira apropriada de ocultar chaves privadas daqueles que têm permissão para usá-las é um módulo de segurança de hardware (um cartão inteligente ou algo assim funciona bem). Você pode fazer isso com algum esforço para chaves SSH (uma pesquisa no google mostra este tutorial sobre ele com alguns hardwares desajeitados e GPG ).

No entanto, se você está preocupado com algo que não é um shell de obter um, tendo em mente que muitos exploits lhe dão um shell, o AppArmour pode restringir as permissões do sistema de arquivos dessa maneira, embora eu acredite fazê-lo dentro dos diretórios home é um pouco mais difícil de gerenciar para sistemas multiusuário.

O SELinux também pode fazer isso; você coloca uma etiqueta de segurança nos arquivos e só permite ssh lê-los .

Lembre-se de que um usuário geralmente pode criar suas próprias chaves SSH, e geralmente é o proprietário delas, o que significa que elas podem ajustar quaisquer rótulos e permissões colocadas. Esta é uma suposição que existe.

Se você estiver executando vírus, existem algumas regras que você pode seguir para torná-lo muito mais seguro do que isso:

• Máquinas que intencionalmente executam vírus devem ser um pouco isoladas. Especificamente, eles devem ser incapazes de agir como uma caixa de salto para qualquer coisa. Eles devem ter acesso limitado à rede (em sua própria VLAN), até o mínimo necessário. Eles nunca devem ter credenciais como chaves privadas X.509 ou chaves privadas SSH que permitam autenticar em qualquer coisa.
• Você precisa manter a capacidade de reconstruir essas máquinas, off-line e rapidamente. Isso torna as VMs instantâneas muito apetitosas para esse tipo de pesquisa.
• Nada do que você gosta deve ser armazenado em máquinas usadas para executar vírus.
• Se os vírus forem criados por você ou se a operação deles estiver sob seu controle, sempre que possível, torne-os inertes. Os endereços C & C devem ser blackholes (192.0.2.1, um IP reservado para testes e documentação, é um bom; o 0.0.0.0 também pode ser apropriado; blackhole.iana.org é um bom nome DNS). Se eles precisam ser endereços reais, você pode hospedar um C & C de teste especial para eles na rede restrita.
• Tenha muito cuidado ao usar o C & C de outra pessoa e um vírus que você não controla. Se você estiver fazendo isso, é melhor fazê-lo no console local em uma conexão de Internet separada, não associada à sua LAN.

Se você está preocupado em acidentalmente administrar um vírus, o selinux pode ajudá-lo, embora a verdadeira solução para isso seja o bom senso e o devido cuidado.

Você também pode proteger suas chaves privadas com senhas, o que faz com que elas sejam criptografadas, embora os vírus possam fazer com que as teclas digitadas ignorem isso.

    

Answer 2

Se o malware for executado usando suas credenciais, não acho que o SELinux seja a ferramenta certa para esse trabalho, pois qualquer coisa que você possa implementar certamente o impediria de acessar a chave também.

As chaves privadas vêm com um mecanismo de segurança integrado que funciona em conjunto e é muito strong. As chaves só podem ser lidas pelo seu dono. Se você adicionar uma senha strong, deve haver muito pouco com o que se preocupar.