Como os arquivos de aplicativos mutuamente não confiáveis são protegidos no Linux?

Question

Estou executando uma máquina Ubuntu Linux. Quando executo aplicativos escritos por diferentes fornecedores, como o Chrome e o Firefox, percebo que todos eles estão sendo executados com o meu uid. Mas se for esse o caso, qualquer arquivo que eles criem no sistema de arquivos também estará com o mesmo uid. Então, como no linux dois aplicativos mutuamente não confiáveis podem manter seus arquivos protegidos uns dos outros?

• o uso de uma política de ACL pelo aplicativo A ainda pode permitir que o aplicativo B leia os arquivos de A - por meio da parte do usuário de (usuário, grupo, outro)
• os aplicativos precisam usar criptografia para proteger seus dados uns dos outros?

Answer 1

A resposta literal é que não existe um aplicativo não confiável em execução na sua conta. Se você deseja executar um aplicativo não confiável, execute-o em uma conta diferente ou em uma máquina virtual.

Sistemas operacionais típicos de desktop, como Unix e Windows, e sistemas operacionais móveis típicos, como Android e iOS, têm modelos de segurança diferentes. Unix é um sistema operacional multiusuário, com usuários mutuamente não confiáveis. Aplicativos são considerados confiáveis: todos os aplicativos de um usuário são executados no mesmo contexto de segurança. Os Serviços , por outro lado, são menos confiáveis: eles são normalmente executados em uma conta dedicada, para reduzir o impacto no caso de uma vulnerabilidade de segurança.

Existem dois motivos principais pelos quais o modelo de segurança Unix funciona desta maneira:

• Uma razão negativa é a história: quando o Unix foi projetado, os aplicativos vieram de um pequeno conjunto de programadores e foram respaldados pela reputação do fornecedor ou fornecidos como código-fonte ou ambos. Backdoors raramente foram temidos em aplicações. Além disso, poucos aplicativos se comunicavam pela rede, portanto, havia relativamente poucas oportunidades para acionar e explorar vulnerabilidades. Portanto, não houve strong incentivo para isolar os aplicativos uns dos outros.
• Uma razão positiva é a funcionalidade: isolar aplicativos impossibilita muitas coisas. Se cada aplicativo tiver sua própria área de dados, isso dificultará o compartilhamento de dados entre aplicativos. Em um sistema Unix típico, é muito comum que os mesmos dados sejam manipulados por vários aplicativos. Isso é especialmente verdadeiro, já que o Unix não possui uma separação clara entre "aplicativos" e "o sistema operacional". Um navegador da web é um aplicativo. Não ser capaz de baixar um arquivo no diretório de sua escolha, porque o navegador está confinado ao seu próprio diretório, é chato. O programa que exibe menus e ícones quando você efetua login também é um aplicativo na mesma base. O mesmo acontece com os gerenciadores de arquivos, que por definição precisam acessar todos os seus arquivos. Assim são os shells e outros intérpretes que executam scripts em todo o lugar. Quando você imprime um documento a partir de um processador de texto, isso pode envolver um aplicativo para converter o documento em um formato imprimível e outro aplicativo para enviar os dados para a impressora.

Embora haja muito mais autores de aplicativos do que há 40 anos, os aplicativos ainda são normalmente distribuídos por meio de canais confiáveis, que possuem uma indicação de reputação. (Isso é mais verdadeiro para o Linux do que para o Windows, o que faz parte do motivo pelo qual os vírus são mais comuns no Windows.) Um aplicativo é considerado um backdoor que seria prontamente retirado dos repositórios de software do Linux.

Os sistemas operacionais móveis foram projetados com diferentes ameaças em mente. Eles foram projetados para sistemas de usuário único, mas com aplicativos provenientes de fontes totalmente não confiáveis.

O isolamento de aplicativos está começando a aparecer nos sistemas Unix de desktop. Algumas distribuições executam certos programas em estruturas de segurança, como AppArmor ou SELinux , que restringe o que o aplicativo pode fazer. O custo dessas restrições de segurança é que, às vezes, tornam impossíveis os usos desejáveis, por exemplo, impedindo que um aplicativo restrito abra arquivos em determinados diretórios.

A criptografia seria completamente inútil. A criptografia apenas protege os dados em trânsito (pela rede) ou em repouso (armazenados em um disco), não protege os dados em um sistema ativo - se o subsistema A descriptografar Em seus dados, cabe ao sistema operacional evitar que o subsistema B impeça o acesso aos dados descriptografados e, portanto, não importa se os dados foram descriptografados por A ou armazenados sem criptografia. O sistema operacional pode criptografar dados, mas apenas para protegê-los caso o meio de armazenamento seja roubado.

Se você deseja executar um código que não confia, a melhor coisa a fazer é executá-lo em uma máquina virtual. Conceda à máquina virtual acesso apenas aos arquivos de que o aplicativo precisa (por exemplo, não compartilhe seu diretório pessoal).

Veja também aplicativos móveis têm permissões refinadas enquanto aplicativos de desktop não? e Por que os aplicativos para dispositivos móveis são mais restritivos que os da área de trabalho?

    

Answer 2

Eu gosto da resposta de Gilles, mas há outro aspecto a considerar:

Um princípio do unix é que cada programa deve "fazer uma coisa bem".

Os programas não deveriam ficar tão grandes e complicados que o usuário não seria capaz de prever o resultado da execução de um. Se um programa unix adequado toca um arquivo, é porque você disse para tocar naquele arquivo. A ideia de que os programas não devem fazer mais e não menos do que eles dizem pelo usuário os impediu de interagir de maneiras que o usuário não pretendia.

Em um exemplo extremo do princípio: um dos antigos mailreaders unix que quase ninguém usa mais, elm , pede sua aprovação antes de criar os diretórios que usará para armazenar seu arquivo de configuração ( ~/.elm/ ) e pastas de email ( ~/Mail/ ). Se você disser não, ele responde com

Very well, but you may run into difficulties later.

O extremo oposto foi demonstrado por algum programa que tentei executar recentemente (desculpe, esqueci qual deles), que se recusou a iniciar e não deu qualquer pista sobre o que estava errado. strace revelou que queria criar um diretório chamado ~/.config/ e não conseguiu, porque eu tinha um arquivo regular com esse nome. (Eu já fiz um cp .config ~ de uma árvore de fontes do kernel, então eu teria um backup.) Aparentemente, agora é considerado razoável pisar em um nome muito genérico no diretório pessoal do usuário sem notificação (muito menos aprovação) ou mesmo verificação mínima de erros.

Progresso.