Em muitos sistemas, um utilizador raiz ou utilizador avançado tem o controlo total do sistema. O Subsistema para Aplicações Baseadas em UNIX (SUA) não reconhece um utilizador raiz. Quando a norma POSIX (Portable Operating System Interface) foi desenvolvida, o conceito de um utilizador raiz foi considerado um problema administrativo. Em vez de um utilizador raiz, a norma POSIX define privilégios adequados para algumas operações.
Neste tópico
Subsistema para Aplicações Baseadas em UNIX e identidades
Considerações de configuração para setuid no Subsistema para Aplicações Baseadas em UNIX
setuid e setgid
Os mecanismos setuid e setgid permitem que um programa, quando executado, adopte determinados aspectos de um principal de segurança que não o do utilizador que executa o programa. Permitem que o programa alterne estes aspectos entre os do utilizador que invoca o programa e os de outro principal de segurança.
Os privilégios adequados são distintos destes. Enquanto os mecanismos setuid e setgid permitem que uma aplicação controle a resposta à pergunta: "Quem é?", os privilégios adequados respondem à pergunta: "O que pode fazer?"
Subsistema para Aplicações Baseadas em UNIX e identidades
Em ambientes UNIX normais, existe um utilizador a quem todos os privilégios são concedidos. Esse utilizador, normalmente denominado root, tem uid == 0. No Subsistema para Aplicações Baseadas em UNIX, todos os privilégios suportados num determinado sistema são concedidos aos utilizadores que são membros do grupo Administradores ou do grupo Administradores de Domínio nesse sistema. Não tem de iniciar sessão como administrador. Qualquer utilizador membro do grupo Administradores ou do grupo Administradores de Domínio dispõe de privilégios root. Nem todos os privilégios definidos no POSIX ou UNIX estão disponíveis no SUA; ou seja, existem determinados privilégios que não são concedidos a qualquer utilizador.
Os privilégios adequados são normalmente necessários para várias acções. Estas incluem aceder ao sistema de ficheiros, enviar sinais para outros processos (controlo de processos) ou alterar o identificador de utilizador efectivo (UID) ou identificador de grupo (GID) para um processo, para poder alterar a capacidade desse processo de executar determinadas acções.
De acordo com a norma POSIX, um ficheiro tem permissões que incluem bits para definir um UID (setuid) e definir um GID (setgid). Se um ou ambos os bits forem definidos num ficheiro e um processo executar esse ficheiro, o processo obtém o UID ou GID do ficheiro. Quando utilizado cuidadosamente, este mecanismo permite que um utilizador não privilegiado execute programas executados com os privilégios mais altos do proprietário ou grupo do ficheiro. No entanto, quando utilizado incorrectamente, pode apresentar riscos de segurança ao permitir que utilizadores não privilegiados executem acções que devem apenas ser executadas por um administrador. Por este motivo, o SUA não suporta este mecanismo por predefinição. Em vez disso, se tentar executar um ficheiro com o bit setuid ou setgid definido, o SUA não executa o ficheiro e devolve o código de erro ENOSETUID.
Considerações de configuração para setuid no Subsistema para Aplicações Baseadas em UNIX
Se se basear numa aplicação que requer o comportamento da norma POSIX, poderá configurar o SUA para executar ficheiros com os bits setuid ou setgid definidos. Se o SUA for configurado desta forma, quando um processo executa um ficheiro com o bit setuid ou setgid definido, o SUA constrói tokens de segurança locais para o processo com os privilégios atribuídos ao proprietário ou grupo do ficheiro. Uma vez que os tokens são locais, não são reconhecidos por outros computadores na rede. Isto significa que, mesmo se o ficheiro pertencer a um membro do grupo Administradores de Domínio, por exemplo, o processo não tem acesso fidedigno através da rede do Microsoft® Windows® para outros computadores no domínio. Em vez disso, os privilégios só serão efectivos no computador no qual o processo está em execução.
Por exemplo, um processo executa um ficheiro de programa com o respectivo bit setuid definido e pertencente a um membro do grupo Administradores de Domínio. Se esse programa tentar alterar a palavra-passe de um utilizador do domínio, essa tentativa vai 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 palavra-passe de um utilizador local, a tentativa vai ter êxito porque o proprietário do ficheiro é membro do grupo Administradores de Domínio, que pertence normalmente ao grupo Administradores do computador local. Para obter informações sobre como configurar o SUA para executar ficheiros com os bits setuid ou setgid definidos, consulte os ficheiros de Ajuda fornecidos com o pacote de transferência Utilitários e SDK (Software Development Kit) para o Subsistema Para Aplicações Baseadas em UNIX.
Para as funções setuid(2), setgid(2) e chroot(2), um processo tem de ter o UID efectivo que efectua o mapeamento para a conta de sistema, a conta de administrador para o domínio local ou a conta de administrador para o domínio principal. A conta de administrador local pode apenas alterar o UID ou GID para outro ID no mesmo domínio.
Para chown(1), chmod(1) e chgrp(1), uma conta tem de ter os privilégios do Windows SE_BACKUP e SE_RESTORE para executar operações make em ficheiros pertencentes a outro utilizador ou grupo, ou para modificar permissões num ficheiro da propriedade de outro utilizador. Estas permissões pertencem normalmente às contas do administrador e do operador de cópia de segurança.