Quando você altera o proprietário ou a propriedade do dispositivo de bloco, não altera nada no sistema de arquivos. O que acontece se vocêchown o dispositivo de bloco para um usuário normal é, que você ignora completamente os direitos de acesso ao sistema de arquivos.
Um dispositivo de bloco é apenas um contêiner que contém dados não estruturados. O sistema de arquivos torna isso estruturado e utilizável. Normalmente, todos os usuários acessam o dispositivo de bloco indiretamente através do sistema de arquivos, pedindo para ler / abrir / gravar arquivos ou pastas. Tudo baseado nos direitos de acesso que são mantidos pelo sistema de arquivos, concedendo ou negando o acesso a um arquivo ou pasta.
Agora, quando um usuário normal tem acesso de leitura / gravação em um dispositivo de bloco, pode-se ignorar esses direitos de acesso do sistema de arquivos, já que você pode "riscar" arquivos diretamente do dispositivo de bloco.
Vamos percorrer.
Primeiro, criamos uma pasta e um arquivo que só é acessível por root , começando com um dispositivo de bloco como deveria ser.
root@host:~# ll /dev/vda1
brw-rw---- 1 root disk 253, 1 Jul 26 18:52 /dev/vda1
root@host:~# mkdir /secure-folder
root@host:~# chmod 700 /secure-folder/
root@host:~# ll -d /secure-folder
drwx------ 2 root root 4096 Jul 27 20:06 /secure-folder/
root@host:~# echo "MySuperSecretText" > /secure-folder/my-secure-file
root@host:~# chmod 400 /secure-folder/my-secure-file
root@host:~# ll /secure-folder/my-secure-file
-r-------- 1 root root 9 Jul 27 19:19 /secure-folder/my-secure-file
Esta pasta e arquivo só podem ser acessados pelo usuário root e, mesmo depois de alterar o proprietário do dispositivo de bloco, ele ainda é o esperado.
user@host:~$ ll /secure-folder/
ls: cannot open directory /secure-folder/: Permission denied
user@host:~$ ll /secure-folder/my-secure-file
ls: cannot access /secure-folder/my-secure-file: Permission denied
root@host:~# chown user /dev/vda1
root@host:~# ll /dev/vda1
brw-rw---- 1 user disk 253, 1 Jul 27 20:16 /dev/vda1
user@host:~$ ll /secure-folder/
ls: cannot open directory /secure-folder/: Permission denied
user@host:~$ ll /secure-folder/my-secure-file
ls: cannot access /secure-folder/my-secure-file: Permission denied
Nesse caso, seu sistema de arquivos está impedindo que user dos arquivos de acesso não tenham direitos de acesso.
Mas como o user tem acesso de leitura / gravação ao dispositivo de bloco, podemos ignorar o sistema de arquivos. vda1 aqui é a partição que está montada em / e debugfs vem com e2fsprogs , portanto, é quase certo pré-instalado.
user@host:~$ debugfs /dev/vda1 -R "ls -l /secure-folder"
67344 40700 (2) 0 0 4096 27-Jul-2017 19:33 .
2 40755 (2) 0 0 4096 27-Jul-2017 19:16 ..
45137 100400 (1) 0 0 18 27-Jul-2017 19:43 my-secure-file
Tudo bem, posso listar as entradas do diretório em uma pasta que não tenho direitos de acesso. Vamos ver o que mais pode ser feito em um arquivo que eu não tenho direitos de acesso.
user@host:~$ debugfs /dev/vda1 -R "cat /secure-folder/my-secure-file"
debugfs 1.42.9 (4-Feb-2014)
MySuperSecretText
Tudo bem, posso ler o conteúdo dos arquivos dessa maneira. Legal. O que mais eu poderia fazer? Vamos criar uma pasta em um lugar que eu normalmente não conseguia.
user@host:~$ debugfs -w /dev/vda1 -R "mkdir /secure-folder/attack"
debugfs 1.42.9 (4-Feb-2014)
root@host:~# ll /secure-folder/
total 16
drwx------ 2 root root 4096 Jul 27 19:33 ./
drwxr-xr-x 25 root root 4096 Jul 27 19:16 ../
drwxr-xr-x 2 root root 4096 Jul 27 20:29 attack/
-r-------- 1 root root 18 Jul 27 19:43 my-secure-file
Ooops. Ele ainda pertence a root , embora eu o tenha criado como user . Hm, o que mais seria possível? Vamos tentar.
Primeiro, precisamos do número de bloco do /secure-folder/my-secure-file .
user@host:~$ debugfs /dev/vda1 -R "blocks /secure-folder/my-secure-file"
debugfs 1.42.9 (4-Feb-2014)
913939
Ok, o número de bloco 913939 contém os dados do arquivo /secure-folder/my-secure-file . Vamos usar dd para obter o conteúdo, 4096 é o tamanho de bloco padrão dos sistemas de arquivos ext4 ou xfs. Novamente possível porque eu posso operar no dispositivo de bloco como um usuário normal.
user@host:~$ dd if=/dev/vda1 of=/tmp/secure-file skip=913939 bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.0214174 s, 191 kB/s
Agora podemos modificar /tmp/secure-file e dd no dispositivo de bloco.
user@host:~$ cat /tmp/secure-file
XxXxxxxSecretText
user@host:~$ dd if=/tmp/secure-file of=/dev/vda1 seek=913939 bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000356448 s, 11.5 MB/s
Por fim, como root user, vamos dar uma olhada no arquivo da visualização do sistema de arquivos. Para torná-lo seguro, primeiro invalidamos todos os caches para obter o conteúdo do disco.
root@host:~# echo 3 > /proc/sys/vm/drop_caches
root@host:~# cat /secure-folder/my-secure-file
XxXxxxxSecretText
root@host:~# ll /secure-folder/my-secure-file
-r-------- 1 root root 18 Jul 27 20:39 /secure-folder/my-secure-file
Eu alterei um arquivo que pertence a root como usuário normal e não tive que alterar nenhum direito de acesso. Tudo baseado no fato de que eu tinha acesso de leitura / gravação ao dispositivo de bloco subjacente.
Este é apenas um exemplo simples e um invasor avançado pode colocar código binário em seu sistema de arquivos ou trocar binários conhecidos por binários maliciosos. Normalmente, as ferramentas utilizadas são pré-instaladas em praticamente qualquer distribuição.
Bem, devo admitir que os direitos de acesso no dispositivo de bloco são recuados quando você reinicia por udev , mas abre um problema de segurança quando você concede acesso de leitura / gravação a um usuário normal a um dispositivo de bloco. / p>
Espero que não seja muito confuso e ajude a entender a diferença entre o sistema de arquivos e o dispositivo de bloco.