Exemplo de situação em que ferramentas inconsistentes de ACL concedem permissões involuntárias

Question

Este documento sobre o arquivo ACLs faz menção de que o mecanismo de mascaramento foi posto em prática para resolver o problema de

... POSIX.1 applications that are unaware of ACLs will not suddenly and unexpectedly start to grant additional permissions once ACLs are supported.

Qual seria um exemplo de tal situação?

Se houvesse um arquivo com configuração de ACLs estendidas de acordo com essas intenções pelo administrador do sistema:

1. O proprietário do arquivo deve ter rwx permissons
2. Os usuários no grupo do arquivo não devem ter acesso ( --- )
3. Outros não devem ter acesso ( --- )
4. Uma exceção aos três acima é que o grupo de sistemas audit tem r-- permissões em arquivos

Eu imagino que a ACL estendida correspondente para um arquivo seria:

# file: path/to/file
# owner: foo
# group: bar
user::rwx
group::---
group:audit:r--
mask::r--
other::---

Neste exemplo, se o mecanismo mask não estava em vigor e uma ferramenta desconhecida de ACLs estendidas tentou alterar as permissões do grupo para --x (é um argumento strawman), a entrada group:: terminaria tendo %código%. Por que isso "inesperadamente ... concede permissões adicionais"?

# file: path/to/file
# owner: foo
# group: bar
user::rwx
group::--x
group:audit:r--
other::---

Com base em meu entendimento, os usuários no grupo proprietário, mas não no group::--x , teriam a capacidade de executar. Usuários no grupo audit , mas não no grupo proprietário, não. Usuários em ambos os grupos ganhariam a capacidade de executar. Eu não entendo porque o audit é necessário.

Se eu estiver entendendo errado, por favor explique. É possível que o meu homem de palha não descreva a situação da qual a citação está falando. Se for esse o caso, por favor descreva essa situação.

    

Answer 1

Se a máscara e seu link para os S_IRWXG bits não foram o caso, os aplicativos que fizeram vários itens padrão com chmod() , esperando que funcionasse como chmod() , tradicionalmente funcionavam em Unixes antigos não ACL, Quer deixar lacunas de segurança ou ver o que eles pensam ser buracos de segurança:

• Aplicativos Unix tradicionais esperam poder negar todo o acesso a um arquivo, pipe nomeado, dispositivo ou diretório com chmod(…,000) . Na presença de ACLs, isso desativa somente todas as permissões de usuário e grupo se o antigo S_IRWXG mapear para a máscara. Sem isso, definir as permissões de arquivo antigo como 000 não afetaria as entradas da ACL para usuários / grupos específicos e outros usuários / grupos, surpreendentemente, ainda teria acesso ao objeto.

  Alterando temporariamente os bits de permissão de um arquivo para nenhum acesso com chmod 000 e, em seguida, alterá-los novamente era um mecanismo antigo de bloqueio de arquivos, usado antes de os Unixes obterem mecanismos de bloqueio consultivo, que - como você pode ver - as pessoas ainda usam hoje .

• Os scripts Unix tradicionais esperam poder executar chmod go-rwx e acabar com apenas o proprietário do objeto capaz de acessar o objeto. Novamente, - como você pode ver - essa ainda é a sabedoria recebida mesmo agora, décadas após a invenção das ACLs Unix. E, novamente, isso não funciona, a menos que o antigo S_IRWXG mapeie para a máscara, porque senão esse comando chmod não desativaria nenhuma entrada ACL para usuários / grupos específicos, levando a usuários / grupos diferentes do proprietário mantendo acesso a algo que é esperado para ser acessível apenas ao proprietário.
• Um sistema em que os bits de permissão eram separados e and ed com as ACLs exigiria que os sinalizadores de permissão de arquivo fossem rwxrwxrwx na maioria dos casos, o que poderia confundir os muitos aplicativos Unix que reclamam quando veja o que eles acham ser coisas que podem ser escritas mundialmente.

  Um sistema em que os bits de permissão eram separados e or ed com as ACLs teria o problema chmod(…,000) mencionado antes.

Leitura adicional

• Craig Rubin (1989-08-18). Justificativa para a seleção de recursos de lista de controle de acesso para o sistema Unix . NCSC-TG-020-A. Publicação DIANE. ISBN 9780788105548.
• Comitê de Padrões de Aplicações Portáteis da IEEE Computer Society (outubro de 1997). Projeto de Norma para Tecnologia da Informação - POSIX (Portable Operating System Interface) - Parte 1: Interface de Programa de Aplicação do Sistema (API) - Alteração #: Interfaces de Proteção, Auditoria e Controle [Linguagem C] IEEE 1003.1e. Rascunho 17.
• link