A chamada do sistema é a única maneira que um programa do usuário pode intencionalmente afetar o estado de um kernel Linux?

Question

Eu acho que existem várias maneiras que um programa de usuário pode intencionalmente afetar o estado de um kernel Linux.

1. Invocando uma chamada do sistema;
2. Invocando mmap () e gravando a memória que foi mapeada para o kernel;
3. Ao carregar um módulo do kernel via insmod .

Eu não consigo pensar de outra maneira. Interrupções de hardware não são consideradas porque elas não são iniciadas por um programa do usuário. Eu acho que ambos mmap () e insmod estão usando chamadas de sistema, então talvez um programa de usuário tenha que confiar em chamadas do sistema para afetar o estado do kernel. Estou correto?

Se eu estiver correto, digamos que haja algumas vulnerabilidades no kernel e um programa de usuário mal-intencionado queira explorá-las para atacar o kernel. É possível verificar todas as chamadas do sistema para defender tais ataques, uma vez que nossa verificação pode sempre dizer a verdade?

    

Answer 1

Como acontece, existe outra interface significativa com o kernel: os sistemas de arquivos /proc e /sys virtual. Enquanto eles não possuem arquivos regulares, seus conteúdos são gateways diretos para o kernel: agir sobre eles é agir diretamente na memória alocada pelo kernel. Por exemplo, se você quiser descartar todos os caches de memória, você pode usar ...

echo 3 > /proc/sys/vm/drop_caches

... e o kernel reagirá imediatamente.

Agora, um programa precisará de chamadas do sistema para interagir com o sistema de arquivos: open , read , write e assim por diante ... No entanto, ainda existe uma maneira de rastrear todas essas chamadas de sistema : o kernel fornece um mecanismo de rastreamento sob /sys/kernel/debug/tracing . Mais especificamente, o rastreamento de chamadas do sistema é tratado por /sys/kernel/debug/tracing/events/syscalls . Esse diretório virtual contém dois subdiretórios para cada chamada de sistema. Por exemplo, com a chamada de sistema aberto, temos:

• sys_enter_open
• sys_exit_open

Nestes diretórios, você encontrará um arquivo chamado enable . Se ele contiver "1", o evento associado (entrada ou saída de uma chamada open ) será rastreado. Eu costumo usar o evento enter , mas você pode escolher o que melhor atenda às suas necessidades.

Depois de ativar o rastreamento de chamada do sistema, você encontrará o log em /sys/kernel/debug/tracing/trace . Agora, tenha em mente que a chamada do sistema open é usada muito . É o gateway final entre um programa e um arquivo, e arquivos podem ser literalmente qualquer coisa em um sistema Linux. Também tenha em mente que ...

UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. — Doug Gwyn

Enquanto você pode monitorar o que acontece no seu sistema, o kernel não tentará impedir os usuários de fazer coisas estúpidas: isso é mais parte do trabalho do administrador de sistemas.

O gerenciamento do mecanismo de rastreamento requer permissões em /sys/kernel/debug/tracing/trace . Você provavelmente precisará ser root para ativar e manipular o traço. Não se esqueça de desativar o rastreamento quando terminar.

    

Answer 2

Depende. O que você quer dizer com 'verificar'? Se você quer apenas monitorar o que alguns processos estão desencadeando, então é possível ... geralmente ... Mas se você sentir vontade de cavar mais fundo, então você está em apuros ... Eu não ouvi falar de nenhuma ferramenta que pudesse fazer isso.

Você pode usar o strace para ver o que o syscalls está executando em algum processo em particular. É claro que você terá que executá-lo como root ... No entanto, você nem sempre será bem-sucedido executando o strace, já que é possível proteger o aplicativo de monitorar sua atividade - as chamadas ptrace são descartadas. Tente colocar no cromo - você verá;)

Se o strace não for suficiente, suponho que você esteja pronto para desmontar cada binário do aplicativo e verificar manualmente o que ele faz. Isso deve ser divertido :) (ou, claro, você pode obter um código-fonte e ver todos esses algoritmos como texto legível por humanos .. mas por que escolher uma maneira mais fácil quando você pode ir com o ASM :))