Em muitos sistemas, um usuário raiz ou superusuário tem controle total sobre o sistema. O Subsistema para Aplicativos Baseados em UNIX (SUA) não reconhece um usuário raiz. Quando o padrão Portable Operating System Interface (POSIX) foi desenvolvido, o conceito de usuário raiz era considerado um problema administrativo. Em vez de um usuário raiz, o padrão POSIX define privilégios apropriados para algumas operações.
Neste tópico
Subsistema para Aplicativos Baseados em UNIX e identidades
Considerações de instalação para setuid no Subsistema para Aplicativos Baseados em UNIX
setuid e setgid
Os mecanismos setuid e setgid permitem que um programa, quando executado, adote determinados aspectos de uma entidade de segurança diferente do usuário que executa o programa. Eles permitem que o programa alterne esses aspectos entre aqueles de que chamam o usuário e aqueles de outra entidade de segurança.
Os privilégios apropriados são distintos disso. Enquanto os mecanismos setuid e setgid permitem que um aplicativo controle a resposta para a pergunta: "Quem é você?", os privilégios apropriados respondem a pergunta: "O que você pode fazer?"
Subsistema para Aplicativos baseados em UNIX e identidades
Em ambientes UNIX típicos, há exatamente um usuário a quem todos os privilégios são concedidos. Aquele usuário, normalmente chamado de root, tem uid == 0. No Subsistema para Aplicativos Baseados em UNIX, todos os privilégios com suporte em um dado sistema são concedidos aos usuários que são membros do grupo Administradores ou do grupo Administradores de Domínio nesse sistema. Você não precisa fazer logon como administrador. Qualquer usuário que seja membro do grupo Administradores ou Administradores de Domínio possui privilégios de root. Nem todos os privilégios definidos no POSIX ou no UNIX estão disponíveis no SUA; ou seja, há alguns privilégios que não são concedidos a nenhum usuário.
Em geral, os privilégios apropriados são necessários para uma variedade de ações. Elas incluem acessar o sistema de arquivos, enviar sinais para outros processos (controle de processo) ou alterar o identificador de usuário (UID) ou identificador de grupo (GID) real de um processo a fim de alterar a habilidade desse processo de executar certas ações.
De acordo com o padrão POSIX, um arquivo tem permissões que incluem bits para definir um UID (setuid) e definir um GID (setgid). Se um ou ambos os bits forem definidos em um arquivo, e um processo executar esse arquivo, o processo obterá o UID ou GID do arquivo. Quando usado com atenção, esse mecanismo permite que um usuário sem privilégios execute programas que são executados com os privilégios mais altos do proprietário ou grupo do arquivo. Quando usado de maneira incorreta, porém, isso pode apresentar riscos de segurança pois permite que usuários sem privilégios executem ações que só deveriam ser realizadas por um administrador. Por esse motivo, o SUA não oferece suporte a esse mecanismo por padrão. Em vez disso, se você tentar executar um arquivo com o bit de setuid ou setgid definido, o SUA não executará o arquivo e retornará o código de erro ENOSETUID.
Considerações de instalação para setuid no Subsistema para Aplicativos baseados em UNIX
Se você depende de um aplicativo que exija o comportamento POSIX padrão, será possível configurar o SUA para executar arquivos com os bits de setuid ou setgid definidos. Se o SUA for configurado dessa maneira, quando um processo executar um arquivo que tenha o bit de setuid ou setgid definido, o SUA construirá tokens de segurança locais para o processo com os privilégios atribuídos ao proprietário ou grupo do arquivo. Como os tokens são locais, eles não são reconhecidos por outros computadores na rede. Isso significa que, mesmo que o arquivo seja de propriedade de um membro do grupo Administradores de Domínio, por exemplo, o processo não terá acesso confiável pela rede Microsoft® Windows® a outros computadores no domínio. Em vez disso, os privilégios entrarão em vigor somente no computador em que o processo for executado.
Por exemplo, um processo executa um arquivo de programa com o bit de setuid definido e cujo proprietário é membro do grupo Administradores de Domínio. Se esse programa tentar alterar a senha de um usuário do domínio, essa tentativa falhará porque os tokens de segurança do processo são locais e não são reconhecidos por outros sistemas no domínio. Se, por outro lado, o programa tentar alterar a senha de um usuário local, a tentativa terá êxito porque o proprietário do arquivo é um membro do grupo Administradores de Domínio, que tipicamente pertence ao grupo Administradores do computador local. Para obter informações sobre como configurar o SUA para executar arquivos com os bits de setuid ou setgid definidos, consulte os arquivos de Ajuda incluídos no pacote de download Utilitários e SDK (Software Development Kit) para Aplicativos baseados em UNIX.
Para as funções setuid(2), setgid(2) e chroot(2), um processo deve ter o UID efetivo que pode ser mapeado na conta do sistema, na conta do administrador do domínio local ou na conta do administrador do domínio principal. A conta do administrador local só pode alterar o UID ou o GID para outro ID no mesmo domínio.
Para chown(1), chmod(1) e chgrp(1), uma conta deve ter os privilégios do Windows SE_BACKUP e SE_RESTORE para executar operações make em arquivos de propriedade de outro usuário ou grupo, ou para modificar permissões em um arquivo de propriedade de outro usuário. Em geral, essas permissões pertencem às contas do administrador e operador de backup.