Algumas questões básicas sobre a segurança do kernel do Linux [closed]

Question

Eu não sei muito sobre o kernel do Linux e tenho algumas perguntas.

1. Qual é o objetivo principal de separar a memória do kernel da memória do espaço do usuário? Para se certificar de que um aplicativo de usuário não pode fazer nada de ruim ao kernel?

2. Quantas maneiras existem para um aplicativo no nível do usuário transferir o controle para o kernel? O que eu posso fazer é incluir (1) invocar uma chamada de sistema, (2) mapear memória para o kernel (mas eu acho que mmap () também é uma chamada de sistema), e (3) carregar uma módulo do kernel (mas eu acho que lsmod também invoca alguma chamada do sistema). Estou correcto? Existem outras maneiras que eu perdi?

3. Quantas maneiras de atacar o kernel? Posso ter alguns detalhes breves sobre eles?

4. Se eu obtiver o privilégio de raiz, isso significa que eu controle completamente o kernel? Ou seja, posso fazer o que quiser com o kernel e o hardware? Ou ainda tenho poder limitado no kernel?

Eu realmente aprecio se alguém puder me ajudar a descobrir a resposta para essas perguntas.

    

Answer 1

Vou tentar responder às perguntas da forma mais breve possível. As perguntas que você está fazendo são geralmente abordadas em cursos de sistemas operacionais introdutórios em universidades, mas eu assumirei que você não fez esse curso.

1. O isolamento de memória para processos do espaço do usuário é muito desejável - não apenas para proteger o kernel de programas maliciosos do espaço do usuário, mas também para proteger os programas do espaço do usuário uns dos outros. Isso geralmente é chamado de Memória Virtual . Também facilita a implementação da paginação, o que é desejável também por outros motivos (fragmentação mais simples, vinculadores / carregadores mais simples, etc.).

2. Interrupções (nem todas estão no controle de um aplicativo no nível do usuário). Desistir do processador também retira o "controle" do processo (por exemplo, wait etc., que também são chamadas do sistema). O kernel pode decidir não programar um aplicativo.

3. Essa é uma questão muito ampla. Kernel com chamadas do sistema mal implementadas é vulnerável. A capacidade de escrever na memória física seria outro caminho. Existem outras vulnerabilidades que podem surgir de instruções mal implementadas (por exemplo, vulnerabilidade sysret em processadores Intel).

4. Privilégios de raiz não são os mesmos privilégios de kernel. Um aplicativo em execução como usuário root ainda está usando a memória virtual, ainda precisa fazer chamadas do sistema, ainda precisa obedecer às outras regras que qualquer aplicativo de nível de usuário precisa.

Se você quiser que eu forneça mais detalhes sobre algumas das respostas, me avise.

Se alguém puder melhorar algumas das respostas, sinta-se à vontade para indicá-lo.