Entendo que /dev/kmem e /dev/mem fornecem acesso à memória (ou seja, RAM bruta) do sistema. Também estou ciente de que /dev/kmem pode ser completamente desativado no kernel e que o acesso pode ser restrito para /dev/mem .
Parece-me que ter acesso bruto à memória pode ser útil para desenvolvedores e hackers, mas por que eu preciso acessar a memória através de /dev/mem . AFAIK não pode ser desativado no kernel (ao contrário de /dev/kmem ). Ter acesso à memória bruta que pode ser potencialmente abusada / explorada parece-me estar apenas a pedir problemas.
Existe algum uso prático para isso? Algum programa de usuário requer que ele funcione corretamente?
Há um conjunto de slides da Escala 7x 2009 intitulado: Minando o kernel do Linux: Injeção de código mal-intencionado via / dev / mem que continha essas duas balas.
Who needs this?
- X Server (Video Memory & Control Registers)
- DOSEmu
De tudo o que encontrei da pesquisa até agora, parece que essas duas balas são as principais candidatas para usos legítimos.
Vale a pena notar que mesmo se você desativou /dev/mem e /dev/kmem essa memória ainda pode ser descartada; dê uma olhada em man proc para revelar /proc/kcore ; é a memória física do sistema. Um kit de ferramentas forense realmente bom o rekall tem uma ferramenta que já faz isso ; ele despeja a memória (e /boot arquivos) para que possam ser analisados.
Na verdade, o Ubuntu por padrão desabilita /dev/kmem :
There is no modern use of
/dev/kmemany more beyond attackers using it to load kernel rootkits.CONFIG_DEVKMEMis set to "n". While the/dev/kmemdevice node still exists in Ubuntu 8.04 LTS through Ubuntu 9.04, it is not actually attached to anything in the kernel.
O Ubuntu não desativa /dev/mem porque é necessário pelos aplicativos .
Some applications (Xorg) need direct access to the physical memory from user-space. The special file
/dev/memexists to provide this access. In the past, it was possible to view and change kernel memory from this file if an attacker had root access. TheCONFIG_STRICT_DEVMEMkernel option was introduced to block non-device memory access (originally namedCONFIG_NONPROMISC_DEVMEM).
/proc/kcore ? Não habilite CONFIG_PROC_KCORE ao construir o kernel. / a>
/dev/mem ? Bem, a pesquisa por man mem nos fornece alguns detalhes sobre como ela foi criada:
mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem
Você deve conseguir apenas rm -rf /dev/mem ; você pode desativar durante a fase de compilação do kernel, não ativando CONFIG_STRICT_DEVMEM .
/dev/kmem ? Assegure-se de que CONFIG_DEVKMEM não esteja habilitado na criação do kernel.
E se eu fosse capaz de desabilitar /proc/kcore , /dev/mem , /dev/kmem e depois usar uma partição de permuta criptografada ou não usar swap? Bem, sua memória pode ser congelada e acessada dessa forma. Como você evita esse ataque? Você criptografa sua RAM; Como você criptografa sua memória RAM? Você não pode. Veja TRESOR para detalhes .
Como você sabe, /dev/mem fornece acesso à memória física de um sistema em execução. /dev/kmem fornece acesso à memória virtual do kernel. Ambos os dispositivos de caracteres podem ser permanentemente desativados através das opções de configuração do kernel ( o código é a fonte de informação mais autorizada, por isso é 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/mem existir, determina se o acesso a é restrito Dependendo da sua distribuição, sua configuração atual do kernel pode ser vista usando algo como zless /proc/config.gz ou less /boot/config-$(uname -r) .
Eu acho que a intenção inicial de /dev/mem era apoiar a interação com memória periféricos mapeados .
As implicações de segurança negativas óbvias de ter esses dispositivos virtuais disponíveis (por exemplo, um invasor capaz de corrigir instantaneamente a memória de outro processo ou mesmo do kernel) são conhecidas há pelo menos uma década.
Restringir o acesso a /dev/mem foi suportado no kernel da linha principal desde o início de 2008 , /dev/kmem também foi opcional desde então também.
Há uma década parece que X dependia de /dev/mem , não acho que isso ainda seja verdade.
Para testar as afirmações sobre X precisando de /dev/mem , excluí o dispositivo virtual do meu laptop ontem e 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.
De uma perspectiva de segurança, é uma boa ideia remover esses dispositivos.
Ainda é importante notar que um atacante remoto , com privilégios elevados, pode ler a memória fora de 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 .