Existe alguma maneira de o invasor usar o mkdir para comprometer um sistema?

Estou configurando uma conta de usuário restrita para usuário ricardo, um usuário problemático no meu sistema. Quero conceder a ele o direito de criar diretórios usando sudo, o que ele às vezes precisa fazer. Estou considerando esta regra no meu /etc/sudoersarquivo:

ricardo   ALL=(root) NOPASSWD: /bin/mkdir

Usando apenas essa regra, existe alguma maneira de Ricardo intencional ou acidentalmente comprometer o sistema?

Eu suspeito que um ataque como este funcionaria, onde «algo» é um módulo do kernel que tentará carregar após a montagem do rootfs:

$ sudo mkdir -m 777 /lib/modules/`uname -r`/a
$ cp evil.ko /lib/modules/`uname -r`/a/«something».ko

Observe também que você pode usar outros nomes, dependendo dos aliases declarados no módulo. Suponho que ele não será carregado até que o depmod seja executado, o que acontecerá na próxima vez que houver uma atualização do kernel - portanto mkdir, nem será exibido recentemente no log do sudo.

Existem muitas coisas no / etc que lêem todos os arquivos em um diretório, às vezes recursivamente. Pior ainda, alguns desses diretórios não existem por padrão, e a única maneira de conhecê-los é ler a página de manual, scripts de inicialização etc. para o programa que os utiliza. Alguns, ainda pior, são itens obsoletos de compatibilidade com versões anteriores e podem nem ser mais documentados.

edit: Pensado em mais alguns diretórios, estes em /usr/local:

• /usr/local/lib/perl/5.14.2(difere dependendo da versão do Perl, tente perl -Vdescobrir). Crie um Filesubdiretório lá e coloque um Find.pmnele. Agora, sempre que alguém usar File::Find, estará usando a versão do atacante. Da mesma forma, faça o mesmo com Getopt::Long. Os utilitários do sistema geralmente são escritos em Perl, portanto, isso provavelmente gera raiz. (Tente ack-grep --color -a 'use.+::' /usr/sbin | less -R)
• Eu acho que Python, Ruby, etc. têm diretórios semelhantes. Os utilitários de sistema também são escritos em Python.
• Subverter muitas coisas que alguém compila com subdiretórios de /usr/local/include.

Ao executar mkdircomo root, o usuário pode impedir que outros processos / usuários criem novos arquivos e diretórios, criando diretórios com nomes idênticos (e / ou direitos errados) antes.

Isso pode ser relevante para a segurança, especialmente com arquivos de log e bloqueio .

Como jordanm observou, o número máximo de inodes também pode ser usado, o que pode bloquear todo o sistema.

Adicionando o usuário a grupos específicos (ou usando ACLs ), você poderá resolver os problemas sem conceder nenhum direito via sudo.

Você deve redirecioná-lo para uma prisão chroot. Ou melhor ainda, para uma pequena VM, que ele pode travar uma vez por hora. Tudo que você precisa fazer é fornecer uma nova cópia.

Existem possibilidades devido à capacidade de criar diretórios com acesso de gravação. Com mkdir -m 777 blaho ricardousuário pode escrever o que quiserem no novo diretório. Você precisaria de um processo no sistema que já esteja sendo executado como um usuário diferente que recuará em uma árvore de diretórios para carregar configurações, scripts ou módulos. Em seguida, o usuário pode adicionar suas próprias coisas para serem carregadas ou executadas. A primeira coisa que consigo pensar é se você executa um servidor Web que pode executar php ou cgi. Você pode então executar scripts como esse usuário. Estou lutando para encontrar mais exemplos do mundo real, especialmente rootaqueles, mas tenho certeza de que são.

ssh é um exemplo de um daemon que captura esse tipo de cenário. Se você criou um .sshdiretório para um usuário que não tinha um e colocou seu próprio authorized_hostsarquivo. sshdpercebe que as permissões dos diretórios são muito abertas e ignora a chave pública.

Você pode definitivamente se incomodar criando diretórios onde os arquivos devem aparecer (como arquivos transitórios tmp ou swap), com os quais muitos programas não lidariam bem.

Você pode criar muitos cgroups, mas parece que você não faz nada com eles. Você pode trazer um sistema de joelhos pelo menos. Foram necessários cerca de 10000 cgroups em uma caixa com 256M para o assassino do OOM remover o sshd.

Se você controla a -mopção mkdire a UMASK do sudoambiente, acho que é apenas um incômodo.