Algumas perguntas básicas sobre a segurança do kernel Linux [fechado]


8

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

  1. Qual é o principal objetivo de separar a memória do kernel da memória do espaço do usuário? Para garantir que um aplicativo de usuário não possa fazer nada de errado com o kernel?

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

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

  4. Se eu receber o privilégio de root, isso significa que eu controlo 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 isso se alguém puder me ajudar a descobrir a resposta para essas perguntas.


1
Existem algumas perguntas boas aqui, mas você poderia dividi-las em perguntas mais específicas com um tópico importante por pergunta?
Caleb

Respostas:


5

Vou tentar responder às perguntas o mais brevemente possível. As perguntas que você faz são geralmente abordadas nos cursos introdutórios de sistemas operacionais das universidades, mas presumo que você não tenha feito esse curso.

  1. O isolamento da 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. Isso geralmente é chamado de memória virtual . Também facilita a implementação de paginação, o que é desejável 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 tira o "controle" do processo (por exemplo, waitetc., que também são chamadas do sistema). O próprio kernel pode decidir cancelar o agendamento de um aplicativo.

  3. Essa é uma pergunta muito ampla. O kernel com chamadas de sistema mal implementadas é vulnerável. A capacidade de gravar na memória física seria outra maneira. Existem outras vulnerabilidades que podem surgir de instruções mal implementadas (por exemplo, vulnerabilidade de sysret nos processadores Intel).

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

Se você quiser que eu forneça mais detalhes sobre algumas das respostas, entre em contato.

Se alguém puder melhorar algumas das respostas, fique à vontade para apontar.


Obrigado por sua resposta. Você disse "Interrupções (nem todas estão no controle de um aplicativo no nível do usuário).", O que significa que apenas as interrupções no software estão no controle do nível do usuário, enquanto as interrupções no hardware não. Está correto?
hebothu

Acredito que o espaço do usuário precise de alguma forma solicitar ao kernelspace que ele lide com algumas das interrupções. Portanto, o kernel ainda está basicamente no controle das interrupções. Em particular, o kernel ainda está manipulando as interrupções e as passa para o espaço do usuário se um aplicativo do espaço do usuário desejar recebê-lo. Pesquisa Linux UIO.
mtahmed
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.