kernel: desativando / dev / kmem e / dev / mem

Eu entendo isso /dev/kmeme /dev/memforneço acesso à memória (ou seja, RAM não processada) do sistema. Também estou ciente de que isso /dev/kmempode ser completamente desabilitado no kernel e que o acesso pode ser restrito /dev/mem.

Parece-me que ter acesso bruto à memória pode ser útil para desenvolvedores e hackers, mas por que eu precisaria acessar a memória completamente /dev/mem? AFAIK não pode ser desativado no kernel (ao contrário /dev/kmem). Ter acesso à memória bruta que pode ser potencialmente abusada / explorada parece-me apenas pedir problemas.

Existe algum uso prático para isso? Algum programa de usuário exige que ele funcione corretamente?

Existe um deck de slides da Scale 7x 2009 intitulado: Minando o kernel do Linux: injeção de código malicioso via / dev / mem que continha esses dois marcadores.

Quem precisa disso?

• Servidor X (Memória de vídeo e registros de controle)
• DOSEmu

De tudo o que encontrei na pesquisa até agora, parece que essas duas balas são as pioneiras em usos legítimos.

Referências

• Anthony Lineberry em / dev / mem Rootkits - LJ 8/2009 por Mick Bauer
• Quem precisa de / dev / kmem?

Vale a pena notar que, mesmo se você desabilitou /dev/meme /dev/kmema memória ainda pode ser despejada; dê uma olhada man procpara revelar /proc/kcore; é a memória física do sistema. Um kit de ferramentas forenses realmente bom rekall tem uma ferramenta que já faz isso ; despeja a memória (e os /bootarquivos) para que possam ser analisados.

Por uma questão de fato, o Ubuntu por padrão desabilita/dev/kmem :

Não há mais uso moderno /dev/kmemalém dos invasores que o utilizam para carregar rootkits do kernel. CONFIG_DEVKMEMestá definido como "n". Embora o /dev/kmemnó do dispositivo ainda exista no Ubuntu 8.04 LTS através do Ubuntu 9.04, ele não está realmente conectado a nada no kernel.

O Ubuntu não desativa /dev/memporque é necessário pelos aplicativos .

Alguns aplicativos (Xorg) precisam de acesso direto à memória física a partir do espaço do usuário. O arquivo especial /dev/memexiste para fornecer esse acesso. No passado, era possível visualizar e alterar a memória do kernel desse arquivo se um invasor tivesse acesso root. A CONFIG_STRICT_DEVMEMopção do kernel foi introduzida para bloquear o acesso à memória que não é do dispositivo (originalmente chamado CONFIG_NONPROMISC_DEVMEM).

Como desativar /proc/kcore?

Não ative CONFIG_PROC_KCOREao criar o kernel.

Como você desativa /dev/mem?

Bem, olhar por cima man memnos dá alguns detalhes sobre como ele foi criado:

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

Você deve ser capaz de apenas rm -rf /dev/mem; você pode desativar durante a fase de construção do kernel não habilitando CONFIG_STRICT_DEVMEM.

Como desativar /dev/kmem?

Certifique-se de que CONFIG_DEVKMEMnão esteja ativado na construção do kernel.

Como evitar ataques de inicialização a frio?

E se eu era capaz de desativar /proc/kcore, /dev/mem, /dev/kmeme depois usou uma partição swap encriptado ou não usar swap em tudo? Bem, sua memória pode ser congelada e acessada dessa maneira. Como você evita esse ataque? Você criptografa sua RAM; Como você criptografa sua RAM? Você não pode. Veja TRESOR para detalhes .

Como você sabe, /dev/memfornece acesso à memória física de um sistema em execução. /dev/kmemfornece acesso à memória virtual do kernel. Ambos os dispositivos de caracteres podem ser desativados persistentemente por meio das opções de configuração do kernel (o código é a fonte de informações mais autoritativa e, portanto, é usado como referência). Desativar as duas primeiras opções abaixo desativará os dispositivos correspondentes.

• CONFIG_DEVKMEM: determina se /dev/kmemé criado na inicialização
• CONFIG_DEVMEM: determina se /dev/memé criado na inicialização
• CONFIG_STRICT_DEVMEM: se /dev/memexistir, determina se o acesso a ele é restrito

Dependendo da sua distribuição, sua configuração atual do kernel pode ser vista usando algo como zless /proc/config.gzou less /boot/config-$(uname -r).

Penso que a intenção inicial /dev/memera apoiar a interação com periféricos mapeados na memória . As implicações negativas óbvias na segurança de ter esses dispositivos virtuais disponíveis (por exemplo, um invasor capaz de corrigir rapidamente a memória de outro processo ou mesmo do kernel) são conhecidas há pelo menos uma década. A restrição de acesso a /dev/memé suportada no kernel da linha principal desde o início de 2008 e /dev/kmemtambém tem sido opcional desde então .

Há uma década, parece que isso Xdepende /dev/mem, acho que ainda não é verdade. Para testar as alegações sobre a Xnecessidade de /dev/memexcluir o dispositivo virtual do meu laptop ontem, ele está funcionando aparentemente perfeito desde então. Em 2017, parece não haver uso prático para esses dispositivos fora da pesquisa e do desenvolvimento.

Do ponto de vista da segurança, é uma boa ideia remover esses dispositivos. Ainda é importante notar que um invasor remoto , com privilégios elevados, pode ler a memória fora do seu espaço de endereço. A memória de outros aplicativos de espaço do usuário pode ser acessada usando /proc/<pid>/mem. A memória do kernel pode ser acessada usando /proc/kcore.

Eu não incluí /dev/memno meu sistema desde o início. Eu uso o Gentoo Linux, então isso pode ser uma surpresa, pois com esta distribuição Linux, você praticamente constrói todos os pacotes, incluindo o kernel do Linux.

Eu nunca notei nenhum problema devido à falta de /dev/mem, mesmo ao usar o X.org X11. Ainda hoje, notei que o surgimento do pacote x11-drivers/xf86-video-vesaimprime uma mensagem informando que ele requer /dev/mem, assim:

* This driver requires /dev/mem support in your kernel
*   Device Drivers --->
*     Character devices  --->
*       [*] /dev/mem virtual device support

Como não instalei o driver VESA para o XServer intencionalmente, ou mesmo apenas como um substituto, nunca precisei usar e, portanto, não o notei - até agora.

Mas isso prova que a) o X11 não precisa /dev/memmais eb) que alguns drivers de vídeo do X11 ainda podem ser necessários.

Drivers de vídeo mais recentes para hardware específico provavelmente funcionarão sem ele. Assim como o X.org-X11 moderno (no Gentoo x11-base/xorg-server), nem precisa ser mais um root , é assim que o progresso se parece ...