Use com segurança o sudo com o sudo

10

Em um servidor Linux, preciso remover privilégios de root de um grupo de usuários. Mas esses usuários têm motivos legítimos para usar o utilitário "find" para pesquisar arquivos com base em nomes de arquivos, datas de modificação e outros metadados.

No servidor, os nomes dos arquivos não são sensíveis, mas o conteúdo do arquivo pode ser.

Eu gostaria de usar o sudo para permitir que os usuários procurem arquivos em qualquer lugar no servidor. O utilitário "find" é ótimo, mas permite todos os tipos de efeitos colaterais, como o uso de "-exec" para gerar comandos arbitrários.

Posso obter find para trabalhar com minhas restrições?

    
por Troels Arvin 03.05.2017 / 13:15

3 respostas

18

O que acha de localizar ?

locate reads one or more databases prepared by updatedb(8) and writes file names matching at least one of the PATTERNs to standard output, one per line. If --regex is not specified, PATTERNs can contain globbing characters. If any PATTERN contains no globbing characters, locate behaves as if the pattern were PATTERN.

By default, locate does not check whether files found in database still exist. locate can never report files created after the most recent update of the relevant database.

Ou talvez até mesmo slocate :

Secure Locate provides a secure way to index and quickly search for files on your system. It uses incremental encoding just like GNU locate to compress its database to make searching faster, but it will also store file permissions and ownership so that users will not see files they do not have access to.

This manual page documents the GNU version of slocate. slocate Enables system users to search entire filesystems without displaying unauthorized files.

    
por 03.05.2017 / 13:20
21

De acordo com man 7 capabilities

   CAP_DAC_READ_SEARCH
          * Bypass file read permission checks and directory read and execute permission checks;
          * Invoke open_by_handle_at(2).

Isso funcionou para mim. (linhas que começam com '#' são raiz, aquelas com '$' são não-raiz) neste caso o usuário não-root está no grupo wheel .

# cp /usr/bin/find /usr/bin/sudofind
# chmod 710 /usr/bin/sudofind
# chown root:wheel /usr/bin/sudofind
# setcap cap_dac_read_search+ep /usr/bin/sudofind
# exit
$ find /root 
find: ‘/root’: Permission denied
$ sudofind /root
/root /root 
/root/Testbed 
...
... 
$ sudofind /root -exec cat {} \;
cat: /root: Permission denied 
cat: /root/Testbed: Permission denied
$ sudofind /root -printf "%u %g %m %c %p\n"
root root 644 Mon Apr 20 09:20:48.0457518493 2015 /root
root root 755 Fri Dec  4 02:34:03.0016294644 2015 /root/Testbed
...
...
$ # Capability inheritance test..
$ sudofind /root -exec /bin/sleep 10 \; &
[1] 17017
$ getpcaps $(pgrep find)
Capabilities for '17017': = cap_dac_read_search+ep
$ getpcaps $(pgrep sleep)
Capabilities for '17019': =

Dado o que a capacidade concede, ela se encaixa exatamente no que você deseja. Eu não verifiquei exaustivamente se find tem um recurso que permite que você leia bytes dentro de arquivos, mas coisas óbvias como LD_PRELOAD e ataques shim da biblioteca não devem funcionar devido à natureza das verificações setuid no Linux, e os bits de capacidade não são herdados pelos processos filhos (ao contrário do setuid bruto), e isso é outro bônus.

Tenha em mente que o que você quer fazer aumenta as possíveis preocupações com privacidade em relação à criação ou acesso a arquivos temporários, e o programa poderia ser usado como base para montar uma tentativa de escalonamento de condição de corrida / privilégio (contra programas que criam bem nomes de arquivos conhecidos, mas não fazem verificações de segurança corretas).

Além disso, alguns aplicativos mal escritos podem depender de metadados de arquivos ou estrutura de árvore para transmitir significado ou ocultar dados. Isso pode causar a liberação de informações restritas ou revelar documentos privilegiados que não são conhecidos (segurança pela obscuridade que eu conheço, mas isso é algo que os fornecedores de código fechado, em particular, gostam de fazer, infelizmente).

Portanto, tome cuidado e seja cauteloso ao fazê-lo e entenda que ainda há risco associado a isso, mesmo que as coisas óbvias não funcionem.

Ah, e eu estaria interessado em ver se alguém tem um ataque de prova de conceito que usa esse mecanismo como base para o escalonamento de privilégios nos comentários!

    
por 03.05.2017 / 14:09
2

Eu daria aos usuários permissões adequadas.

Por padrão, se o umask for 022 , os diretórios serão criados para que todos possam listar e registrar os arquivos neles. Caso contrário, você pode alterar manualmente a permissão do diretório para ser o bit a bit ou de suas permissões antigas e 0555 :

chmod +0555 foo

E se esses usuários não tiverem permissão de execução em todos os pais desse diretório (por exemplo, o diretório pessoal de outro usuário), isso provavelmente significa que você deve colocar o primeiro diretório em algum outro lugar.

Se você quiser permitir que apenas alguns usuários leiam e executem esse diretório, você poderá alterar seu modo para 0750 , colocar esses usuários em um grupo e alterar o proprietário do grupo do diretório para esse grupo:

groupadd can_read_foo
chmod 0750 foo
chgrp can_read_foo foo
gpasswd -a alice can_read_foo
gpasswd -a bob can_read_foo
    
por 03.05.2017 / 16:34

Tags