Enganche a ação na criação do processo

Question

É possível ligar uma execução de script na criação de cada processo?

Essencialmente, o equivalente a inotifywait para monitorar a atividade do disco, mas aplicado à tabela de processos.

Seria permitir fazer uma ação após a propagação dos processos, por exemplo, registrá-lo, cgset-lo, outro. Eu posso ver o desafio que se aplicaria recursivamente nos novos processos. Mas em vez de pesquisar a tabela de processos o mais rápido possível para detectar mudanças que seriam vulneráveis a condições de corrida, existe uma maneira melhor.

Obrigado

    

Answer 1

Primeiro, a criação de processos raramente é um evento útil para registrar e é irrelevante para segurança (exceto para limitação de recursos). Eu acho que você quer ligar a execução de programas, o que é feito por execve , não fork .

Em segundo lugar, os casos de uso que você cita geralmente são mais bem-sucedidos usando o mecanismo existente criado para essa finalidade, em vez de usar o seu próprio.

• Para o registro em log, contabilidade do processo do BSD fornece uma pequena quantidade de informações e está disponível em a maioria das variantes Unix; no Linux, instale os utilitários de contabilidade GNU (instale o pacote da sua distribuição). Para um registro mais sofisticado no Linux, você pode usar o subsistema de auditoria (a página do manual auditctl tem exemplos; como expliquei acima, chamada do sistema que você deseja registrar é execve ).
• Se você quiser aplicar restrições de segurança a determinados programas, use uma estrutura de segurança como SELinux ou AppArmor .
• Se você quiser executar um programa específico em um contêiner ou com determinadas configurações, mova o executável e coloque um script de invólucro em seu lugar que defina as configurações desejadas e chame o executável original.

Se você quiser modificar a maneira como um programa específico chama outros programas, sem afetar como os outros programas se comportam, há dois casos: ou o programa é potencialmente hostil ou não.

• Se o programa for potencialmente hostil, execute-o em uma máquina virtual dedicada.
• Se o programa é cooperativo, o ângulo de ataque mais óbvio é executá-lo com um PATH diferente. Se o programa usa caminhos absolutos que não são fáceis de configurar, em um sistema Linux não antigo, você pode executá-lo em um mount namespace (veja também kernel: suporte a Namespaces ). Se você realmente precisa de um bom controle, você pode carregar uma biblioteca que substitui algumas chamadas da biblioteca invocando o programa com LD_PRELOAD=my_override_library.so theprogram . Consulte Redirecionar um descritor de arquivo antes da execução para um exemplo . Observe que, além de execve , você precisará substituir todas as funções da biblioteca C que chamam execve internamente, porque LD_PRELOAD não afeta as chamadas internas da biblioteca C. Você pode obter um controle mais preciso executando o programa em ptrace ; isso permite que você sobrescreva uma chamada de sistema, mesmo que seja feita por uma função de biblioteca C, mas é mais difícil de configurar (não sei de nenhuma maneira fácil de fazer isso).

Answer 2

//fakeExec.c
#include <unistd.h>
#include <stdio.h>
#include <sys/syscall.h>
int execve(const char *path, char *const argv[], char *const envp[]) {
  printf("Execing \"%s\"\n", path);
    return syscall(SYS_execve, path, argv, envp);
}

No terminal:

$ gcc -fPIC -shared fakeExec.c -o fakeExec.so
$ export LD_PRELOAD=$PWD/fakeExec.so 

E agora você deve obter todos os novos arquivos executados logados em stdout .

Um empacotador de garfo aparentemente exigiria um pouco mais de trabalho para ser feito corretamente.

( O tipo de wrapper fork trivial (como o acima, mas para fork , em vez de execve ) funciona, mas leva a alguns erros setgpid nos processos gerados com ele.

Aparentemente, o libc fork funciona um pouco mais, o que eu não entendo muito bem. )