As permissões de arquivo do Linux podem ser enganadas?

Question

Eu me deparei com esse exemplo hoje e me perguntei como as permissões de arquivo do Linux são confiáveis para ocultar informações

$ mkdir fooledYa
$ mkdir fooledYa/ohReally
$ chmod 0300 fooledYa/
$ cd fooledYa/
$ ls 
>>> ls: cannot open directory .: Permission denied
$ cd ohReally
$ ls -ld .
>>> drwxrwxr-x 2 user user 4096 2012-05-30 17:42 .

Agora eu não sou um especialista em Linux, então não tenho dúvidas de que alguém lá fora me explicará que isso é perfeitamente lógico do ponto de vista do sistema operacional. No entanto, minha pergunta ainda permanece, é possível enganar, não hackear, o sistema operacional para permitir que você visualize arquivos / inode info que você não deveria? E se eu tivesse emitido o comando chmod 0000 fooledYa , um programador experiente poderia encontrar alguma maneira de ler um arquivo como fooledYa/ohReally/foo.txt ?

    

Answer 1

$ ls -lhd fooledYa/
d-wx------ #snip

A primeira coisa é a primeira: posso escrever no diretório (fazer novas entradas) e posso executar ( cd ) no diretório. Eu não posso ler o diretório, no entanto. O que isso significa não é intuitivo.

Quando você trabalha com diretórios em sistemas Unix, o diretório aponta para inodes , que são coisas diferentes da entrada do ponteiro . Ser capaz de seguir referências em uma árvore de diretórios é controlado pelo eXecute bit. Para cada nível de diretório na árvore, o sistema operacional verifica o bit de execução antes de descer para o próximo nível.

Enquanto isso, o Read bit controla o acesso ao conteúdo do inode. Tudo o que você pode referenciar em seu sistema de arquivos é uma entrada inode. Diretórios ou arquivos, eles apontam para um inode.

ls -ldi fooledYa/
121100226 d-wx------ #snip

Neste caso, o diretório inode é 121100226. A permissão de leitura informa se posso acessar esse arquivo inode no espaço do usuário para ler seu conteúdo. O conteúdo do diretório inode é a referência a outros arquivos. O kernel sempre pode ler isso. Você, como usuário, é controlado pelas decisões do kernel em relação às entradas dentro dele.

Assim, como ls tenta ler o conteúdo para me informar o que está lá (conforme marcado pelo Read flag), isso é negado. Desde que eu ainda tenho eXecute permissão, no entanto, o kernel irá permitir-me atravessar para arquivos que eu especificar se os diretórios acima do arquivo que eu quero todos permitem-me eXecute neles, independentemente se eu posso lê-los para ver qual a referência.

Portanto, para resumir para diretórios, pense em executar como uma permissão principal. Sem isso, você não pode entrar no diretório para fazer nada. Depois disso, pense neles como um arquivo de duas colunas. Se você tiver permissão de leitura, poderá ver as entradas. Se você tiver permissão de gravação, poderá adicionar ou remover entradas. Se você não tiver essas duas permissões, mas tiver executado, poderá fazer referências a entradas na lista, mas não poderá ler a lista.

Este é um bom exemplo ilustrativo de inodes e como eles representam referências de diretório e bloco de arquivos em referências de disco: link

    

Answer 2

Acredito que a coisa específica que está lhe enganando é que cada diretório abaixo de / tem pelo menos dois links para ele: a entrada do diretório em seu pai e . dentro de si (mais quaisquer .. links de diretórios filhos ). Quando você digita ls -ld . , ele está observando o link . no diretório atual (que você tem permissão para ler), não o link para o diretório atual do diretório pai (que você não tem permissão para ler).

Para + x, descobri que a maneira mais fácil de entender como funciona nos diretórios é a permissão para "entrar" no diretório. Você não pode entrar em um diretório sem + x, mesmo que tenha acesso de leitura e gravação a ele. Se você não tiver permissão para entrar em um diretório, não poderá entrar nos subdiretórios se eles tiverem + x configurado ou não. Portanto, se você tiver fooledYa/ohReally/foo.txt e fooledYa is for chmod 0000, supondo que nenhum outro sistema ACL substituirá o modo de arquivo, somente o root poderá entrar em ohReally/ ou abrir foo.txt mesmo que conheça o caminho para o arquivo sem ter que listar o conteúdo do diretório.

Uma das coisas estranhas sobre essas permissões é que, se o diretório for + r, mas não + x, você terá permissão para ler o conteúdo do diretório para poder "espiar" de fora e ler a lista de arquivos no diretório, mas sem + x você não poderá entrar no diretório para acessar ( stat ) os arquivos individuais. Portanto, se você tentar ls -l tal diretório, você obterá nomes de arquivos, mas todos os outros campos para filesizes, modos, propriedade, etc. serão ? marks.

    

Answer 3

Como você previu, muitas pessoas explicaram como seu exemplo é perfeitamente lógico. "Funciona como projetado."

Para responder à sua pergunta, seria um erro grave do kernel se você conseguisse enganar o sistema operacional para permitir que você visualizasse os arquivos / informações do inode que você não deveria. As permissões de arquivo estão associadas com o próprio inode e são aplicados quando você realmente tenta abrir o arquivo. Caso você não tenha recebido as outras respostas, mostrarei que um diretório tem um inode como qualquer outro arquivo, é apenas que as permissões significam algo um pouco (ou muito) diferente quando aplicado aos diretórios.

As permissões de arquivo são o mecanismo de segurança original do Unix e ainda fazem parte da segurança do Unix / Linux. Qualquer cenário que você possa imaginar que tenha enganado o sistema é quase certamente um caso de você não entender qual é o comportamento correto. Se você encontrasse uma maneira legítima de contornar a segurança, mesmo em hacks, isso seria considerado um bug crítico de segurança e estaria entre as maiores prioridades a serem corrigidas.

Por exemplo, se você fosse capaz de ler o conteúdo de um arquivo que não deveria poder ler, você poderia roubar as senhas (hash) de todos os usuários e a chave ssh privada para o sistema e as chaves ssh privadas de todos no sistema (embora esperamos que elas sejam criptografadas) e, por meio de um dispositivo inode, leia todo o conteúdo da memória do sistema (e muito mais). Seria menos perigoso se você pudesse ler informações de arquivo que você não deveria, mas ainda assim seria considerado uma violação importante.