Quando instalo um programa como o GIMP ou o LibreOffice no Linux, nunca me perguntam sobre permissões. Ao instalar um programa no Ubuntu, estou explicitamente dando a esse programa permissão total para ler/gravar em qualquer lugar da minha unidade e acesso total à Internet?
Teoricamente, o GIMP poderia ler ou excluir qualquer diretório em minha unidade, sem exigir uma senha do tipo sudo?
Só estou curioso para saber se é tecnicamente possível, não se é provável ou não. Claro, eu sei que não é provável.
Há duas coisas aqui:
quando você instala um programa por meios padrão (instalador do sistema como apt/apt-get no Ubuntu), ele geralmente é instalado em algum diretório onde está disponível para todos os usuários (/usr/bin...). Este diretório requer privilégios para serem gravados, então você precisa de privilégios especiais durante a instalação.
quando você usa o programa, ele é executado com seu id de usuário e só pode ler ou escrever onde os programas executados com seu id têm permissão para ler ou escrever. No caso do Gimp, você descobrirá, por exemplo, que não pode editar recursos padrão, como pincéis, porque eles estão no compartilhado
/usr/share/gimp/e você deve copiá-los primeiro. Isso também mostraEdit>Preferences>Foldersonde a maioria das pastas vem em pares, uma do sistema que é somente leitura e uma do usuário que pode ser gravada.Sim, se você usar
sudoou equivalente, estará dando ao instalador permissão total para ler/gravar em qualquer lugar de sua unidade. Isso é basicamente a mesma coisa. Há também um sinalizador que o instalador pode definir, chamado setuid, que fará com que o programa também tenha permissões totais após a instalação.Mesmo se ignorarmos o instalador e se o programa não for setuid (é muito raro os programas usarem setuid), quando você executar o programa, ele terá acesso total a qualquer coisa que sua conta possa acessar. Por exemplo, se você estiver conectado ao seu banco on-line, ele hipoteticamente poderá enviar todos os seus fundos para a Nigéria.
O modelo de segurança - ou seja, a forma como o sistema de segurança é projetado - no Linux é muito antigo. É herdado do Unix, que remonta à década de 1960. Naquela época, não havia Internet e a maioria das pessoas em um departamento usava o mesmo computador. A maioria de seus programas veio de grandes empresas confiáveis. Portanto, o sistema de segurança foi projetado para proteger os usuários uns dos outros, não para proteger os usuários dos programas que executam.
Hoje em dia está bastante desatualizado. O Android é baseado no Linux, mas funciona criando uma "conta de usuário" separada para cada aplicativo, em vez de para cada usuário. Não sei o que o iOS usa. Esforços como o Flatpak estão tentando trazer o mesmo tipo de coisa para a área de trabalho do Linux.
O que você deseja está sendo fornecido pelos aplicativos Flatpack. Eles são muito equivalentes aos aplicativos iOS, Android ou Windows Store.
Não os usei, então não sei se eles já implementaram a GUI, para ver as permissões exigidas por cada aplicativo quando instalado.
https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-security-model-part-2-who-needs-sandboxing-anyway/
Também não usei a alternativa do Ubuntu, Snappy, para saber se ele fornece esse recurso visível na GUI.
É tecnicamente possível e as soluções incluem
apparmor,selinuxefirejailou mesmo contêineres completos comoLXCou uma máquina virtual completa (por exemploVirtualBox,kvmouvmware). Para redes existeopensnitchum clone dolittlesnitchprograma da OSX.As razões pelas quais não existe um modelo de segurança generalizado com permissões dadas pelo usuário é que tradicionalmente você toma cuidado com o que executa em seu pc. 90% do que está nas lojas de aplicativos de sistemas móveis seria considerado malware em PCs.
Existem scanners para adware (ou seja, adaware ou Spybot D&D) que classificariam comportamentos como conectar facebook, google analytics e redes de publicidade como malware no PC. O ecossistema móvel é como uma reinicialização completa da computação quando se trata dessas coisas. Todos agrupam adware, apenas porque é fácil e adicionam análises, apenas porque estão curiosos. Os efeitos colaterais são diminuição da privacidade e segurança. A parte de segurança é contabilizada pelo modelo sandbox, a parte de privacidade ainda é um problema em aberto.
Outro motivo para não ter isso no PC por muito tempo é a complexidade de um sandbox, o que significa que pode ser muito lento para PCs mais antigos há algum tempo e exigia mais engenharia para algo que tinha pouca vantagem na época.
Hoje, vemos tentativas de usar o sandbox em novos formatos de pacote, como snap e flatpak, e os navegadores também o usam para suas extensões. O Chromium usa um modelo de permissão desde o início e o Firefox usa um para todas as extensões da web (desde 57 as únicas extensões que você pode instalar). Isso é bastante razoável, porque as pessoas instalam extensões de navegador de autores desconhecidos, assim como aplicativos de pessoas de quem nunca ouviram falar, pensando que não são mais perigosos do que um site que visitam, o que é um equívoco fatal quando não há sandbox para protegê-los.
O Android usa um modelo de segurança de "mercado": aplicativos diferentes vêm de fornecedores diferentes (semiconfiáveis) e devem ser isolados dos recursos protegidos e uns dos outros. A maioria dos aplicativos é distribuída com fins lucrativos: eles são vendidos (payware), exibem publicidade paga ou "monetizam" seus usuários vendendo seus dados a terceiros. Há uma alta motivação para se envolver em acesso ilícito a dados, mesmo que sejam pegos.
A maioria dos aplicativos no Debian, Red Hat e distribuições Linux "clássicas" semelhantes são distribuídas na forma de código-fonte: depois que um aplicativo de código aberto ganha força suficiente, ele é escolhido manualmente para inclusão pelos mantenedores da distribuição. Há pouca motivação para realizar acesso ilícito a dados, — ganhos potenciais não justificam esforços.
Vale a pena notar que o modelo de segurança avançada do Android é uma das razões pelas quais ele ganhou tanta força, superando facilmente o iOS nos mercados móveis. As distros modernas do Linux para desktop não são apenas "diferentes" - na verdade, estão bem atrasadas em termos de segurança e modelos de distribuição.
Algumas das distribuições Linux estão apresentando melhorias em seu sistema de distribuição de software: repositórios centralizados de software de terceiros (AUR), formatos de pacotes especializados para distribuição de software de terceiros (AppImage, Snappy, Flatpack), sistemas de repositório secundário (Docker). Infelizmente, essas melhorias ganham muito pouca força com o tempo: o AppImage foi inventado em 2004, a primeira versão do AUR foi lançada em 2005, mas nenhuma das distribuições modernas do Linux adotou oficialmente seus recursos após mais de 10 anos.
Esses aplicativos são instalados em uma parte privilegiada do sistema de arquivos que você e a maioria dos usuários normalmente não têm acesso para alterar.
Em distribuições convencionais configuradas para uso em desktop, o único usuário inicialmente configurado durante a instalação normalmente terá direitos de administrador. Tudo o que eles normalmente serão solicitados é sua própria senha de login para instalar o software, e nem sempre isso.
Uma vez instalado, o software será, por padrão, configurado para ser executável por usuários normais e permitir a leitura de arquivos de dados. Isso é tudo o que é necessário.
Não o programa. O que acontece é que a conta do usuário pertence a diferentes grupos e os diferentes grupos concedem acesso a diferentes recursos.
O modelo de segurança no Linux é que sua conta de usuário tem certos direitos e os grupos aos quais sua conta pertence têm direitos específicos. O direito a qualquer parte do sistema de arquivos requer privilégios de root, que normalmente não são concedidos aos usuários. Mesmo quando você usa o sudo , você não obtém todos os direitos.
As contas de usuário normais geralmente têm acesso aos recursos de que se espera que precisem, como a Internet.
Qualquer diretório ou arquivo que você, como usuário, tem direitos de acesso pode ser acessado pelo aplicativo que você inicia, pois normalmente herda seus direitos. Um usuário normalmente conectado não terá, por padrão, o direito de alterar a maioria dos arquivos críticos do sistema ou arquivos compartilhados.
Lembre-se de que a maioria dos usuários normalmente instala aplicativos de repositórios bem controlados e o risco de código hostil é baixo.
Eu provavelmente sugeriria alguma leitura adicional para entender as permissões do Linux.
Uma introdução às permissões do Linux
Compreendendo as permissões de arquivos do Linux
O modelo de segurança do Android está evoluindo para atender às necessidades dos usuários que geralmente não entendem nada sobre o modelo de segurança subjacente do sistema operacional, mas também quase não entendem nada sobre computadores.
O modelo Linux (que eu francamente gosto mais) é projetado para permitir que usuários (e administradores em particular) exerçam mais controle sobre a segurança do sistema (dentro dos limites permitidos por suas permissões).
Acho que, do ponto de vista do usuário, é melhor descrito como a diferença entre controle totalmente automático e semiautomático ou manual. Os consumidores modernos querem automóveis completos. Linux tem semi-automático e manual. A maioria dos usuários do Linux nunca precisa saber sobre o modelo de segurança hoje em dia, mas o controle está lá se você precisar ou quiser.
Ao instalar alguns programas, você pode instalá-los em seu próprio espaço de usuário (ou seja, autocontido em seu diretório inicial) e não em todo o sistema. Dessa forma, você não está sendo solicitado a conceder privilégios de superusuário porque não precisa deles para instalar um programa para uso próprio de um usuário. Um programa assim instalado não seria realmente capaz de acessar arquivos não concedidos à permissão "não-proprietários e membros do grupo podem ler isto" sem uma escalação de privilégio.