Este é um argumento de que a segurança do Linux não é impenetrável?

Question

Pelo que entendi, a maior e provavelmente a única linha de defesa contra software não autorizado (vírus e worms) que está sendo instalada no sistema é simplesmente não permitir, a menos que uma senha de administrador tenha sido fornecida.

Mas e cavalos de tróia? Digamos que um ser humano consiga hackear um repositório PPA confiável e infectar vários pacotes legítimos com vírus (por uma questão de propósito - alguém infecta f.lux ou vinho com um vírus que reproduz um enorme loop Nyan Cat nas camadas superiores de a tela com música extra alta). O próximo usuário que baixa o pacote é infectado porque permitiu que o programa fosse instalado. Eles nunca pensaram na possibilidade de um cavalo de Tróia.

O trojan é provavelmente removido rapidamente por um dos muitos milhares de olhos que observam a comunidade Linux, mas há boas chances de que pelo menos alguns usuários sejam infectados. A definição de um vírus é algo que se instala em um sistema de computador sem o consentimento de um ser humano autorizado, e se reproduz infectando mais sistemas dessa maneira. Se isso acontecer, eles têm um vírus.

Isso é um argumento contra a segurança supostamente impenetrável do Linux?

    

Answer 1

Primeiro, qualquer um que afirme que o Linux (ou qualquer outro SO que não seja brinquedo) seja impenetrável é insensato, na melhor das hipóteses. Alguns são mais difíceis de penetrar do que outros (o OpenBSD é famoso por ser um dos mais difíceis); muitos (incluindo o Linux e até o Windows Server) podem ser seguros se mantidos por administradores competentes com suporte organizacional suficiente (tempo suficiente, recursos, etc.). A quantidade de esforço / tempo / despesa varia entre as plataformas; reivindicações razoáveis são sobre quais as que levam mais ou menos. Muitos problemas de segurança, a propósito, vêm dos aplicativos instalados no sistema - não do sistema operacional.

Os repositórios do apt hoje em dia devem ser assinados por GPG, o que cria uma prova criptográfica de integridade do mantenedor do repositório. Se alguém invadir o servidor e compactar com um dos pacotes, sua soma de verificação não corresponderá ao arquivo Pacotes (e se eles alterarem isso, isso não corresponderá ao arquivo de Liberação e, se eles violarem isso, a assinatura irá falhar).

É claro que, se um invasor conseguir roubar a chave privada do mantenedor, o invasor poderá colocar pacotes maliciosos no repositório. Deveria haver (pelo menos para um repositório confiável!) Algumas defesas que tornam isso difícil:

• A chave privada deve ser criptografada com uma senha segura, conhecida apenas pelo (s) mantenedor (es).

• A chave privada deve ser armazenada em uma máquina segura com acesso limitado, não no servidor da Web acessível publicamente. Ainda melhor é armazená-lo em hardware resistente a violação (por exemplo, um cartão inteligente).

Por fim, se o repositório for comprometido e você instalar um pacote mal-intencionado, sua máquina ficará comprometida. Não use repositórios nos quais você não confia.

    

Answer 2

Eu acredito que um dos mecanismos de defesa contra isso, é que existe uma soma de verificação nesses pacotes, e se um pacote foi alterado, a soma de verificação indicada não corresponderia à computada, então é claro que você poderia imaginar que o hacker poderia modificar a soma de verificação para refletir o novo pacote fraudulento, mas primeiro seria difícil, e segundo, nenhum sistema é perfeito ...