Действительно ли изменение является владением/полномочиями блочного устройства, эквивалентным изменению ownrshp/perms файловой системы? Это - что-то, что можно было бы хотеть сделать?

При изменении владельца или владения блочного устройства Вы ничего не изменяете в файловой системе. Что происходит если Вы chown блочное устройство обычному пользователю, что Вы полностью обходите права доступа к файловой системе.

Блочное устройство является просто контейнером, который содержит неструктурированные данные. Файловая система делает, это структурировало и применимый. Обычно все пользователи получают доступ к блочному устройству косвенно через файловую систему, прося читать/открывать/писать файлы или папки. Все на основе прав доступа, которые сохраняются файловой системой, предоставляя или запрещая доступа к файлу или папке.

Теперь, когда у обычного пользователя есть доступ для чтения-записи на блочном устройстве, можно обойти те права доступа файловой системы, поскольку можно "поцарапать", файлы непосредственно формируют блочное устройство.

Давайте идти через.

Сначала мы создаем папку и файл, который только доступен root, Начиная с блочного устройства, как это должно быть.

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

К этой папке и файлу можно только получить доступ root пользователь и даже после изменения владельца блочного устройства, это все еще, как Вы ожидали бы.

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

В этом случае Ваша файловая система предотвращает user из файлов доступа, к которым это не имеет прав доступа.
Но начиная с user имеет доступ для чтения-записи к блочному устройству, мы можем обойти файловую систему. vda1 вот раздел, который смонтирован на / и debugfs идет e2fsprogs, так вполне уверен предварительно установленный.

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

Хорошо, я могу перечислить записи каталога в папке, у меня нет прав доступа. Давайте посмотрим то, что еще может быть сделано на файле, на котором у меня нет прав доступа.

user@host:~$ debugfs /dev/vda1 -R "cat /secure-folder/my-secure-file"
debugfs 1.42.9 (4-Feb-2014)
MySuperSecretText

Хорошо, я могу считать содержание файлов этот путь.Круто. Что еще я мог сделать? Давайте создадим папку в месте, я обычно не мог.

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. Это даже принадлежит root хотя я создал его как user. Гм, что еще было бы возможно? Давайте попробуем.

Сначала нам нужен номер блока /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 

Хорошо, номер блока 913939 содержит данные файла /secure-folder/my-secure-file. Давайте использовать dd получить содержание, 4096 размер блока по умолчанию ext4 или xfs файловых систем. Снова возможный, потому что я могу воздействовать на блочное устройство как обычный пользователь.

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

Теперь мы можем изменить /tmp/secure-file и dd это назад на блочном устройстве.

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

Наконец, как root пользователь позволяет нам взглянуть на файл от представления файловой системы. Для создания этого безопасным, мы сначала делаем недействительным все кэши для получения содержания диска.

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

Я изменил файл, который принадлежит root как обычный пользователь и не должен был изменять права доступа. Все на основе того, что у меня был доступ для чтения-записи к базовому блочному устройству.
Это - только простой пример, и усовершенствованный взломщик мог поместить двоичный код в Вашу файловую систему или обмениваться известными двоичными файлами со злонамеренными. Обычно используемые инструменты предварительно установлены почти на любом распределении.

Ну, я должен признать, что права доступа на блочном устройстве задержаны, когда Вы перезагружаете udev, но это открывает проблему безопасности, когда Вы даете доступ для чтения-записи обычному пользователю к блочному устройству.

Надежда это не слишком сбивает с толку и помогает понять различие между файловой системой и блочным устройством.