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

Question 1

Некоторое время назад мне удалось петлевать гитару на динамиках без заметной задержки, поэтому pulseaudio поддерживает это, но я помню, что у меня были проблемы с задержками менее 10 мс. Мои предложения:

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

Question 2

Когда вы меняете владельца или владельца блочного устройства, вы ничего не меняете в файловой системе. Что произойдет, если вы 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, но он открывает проблему безопасности, когда вы дать доступ на чтение / запись нормальному пользователю к блочному устройству.

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

Question 3

Question 4

Когда вы меняете владельца или владельца блочного устройства, вы ничего не меняете в файловой системе. Что произойдет, если вы 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, как обычный пользователь и не должен был изменять какие-либо права доступа , Все это основано на том, что у меня был доступ на чтение / запись к базовому блочному устройству. [D7] Это всего лишь простой пример, и продвинутый злоумышленник может помещать двоичный код в вашу файловую систему или обменивать известные двоичные файлы на вредоносные , Обычно используемые инструменты предварительно установлены практически для любого дистрибутива.

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

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

Question 5

Когда вы меняете владельца или владельца блочного устройства, вы ничего не меняете в файловой системе. Что произойдет, если вы 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, как обычный пользователь и не должен был изменять какие-либо права доступа , Все это основано на том, что у меня был доступ на чтение / запись к базовому блочному устройству. [D7] Это всего лишь простой пример, и продвинутый злоумышленник может помещать двоичный код в вашу файловую систему или обменивать известные двоичные файлы на вредоносные , Обычно используемые инструменты предварительно установлены практически для любого дистрибутива.

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

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

Question 6

Я думаю, вы неправильно понимаете смысл. как член группы sudo, у вас есть доступ к R / W по умолчанию. Это не означает, что вы на самом деле корневые, просто чтобы у вас был аналогичный доступ в зависимости от того, как настроено sudo.

Дальнейшее чтение:

, как настроено sudo.

https://www.tecmint.com/su-vs-sudo-and-how-to-configure-sudo-in-linux/

Question 7

Question 8

Я думаю, вы неправильно понимаете смысл. как член группы sudo, у вас есть доступ к R / W по умолчанию. Это не означает, что вы на самом деле корневые, просто чтобы у вас был аналогичный доступ в зависимости от того, как настроено sudo.

Дальнейшее чтение:

, как настроено sudo.

https://www.tecmint.com/su-vs-sudo-and-how-to-configure-sudo-in-linux/

Question 9

Я думаю, вы неправильно понимаете смысл. как член группы sudo, у вас есть доступ к R / W по умолчанию. Это не означает, что вы на самом деле корневые, просто чтобы у вас был аналогичный доступ в зависимости от того, как настроено sudo.

Дальнейшее чтение:

, как настроено sudo.

https://www.tecmint.com/su-vs-sudo-and-how-to-configure-sudo-in-linux/

Thomas · Accepted Answer · 22 May 2018 в 20:10

Когда вы меняете владельца или владельца блочного устройства, вы ничего не меняете в файловой системе. Что произойдет, если вы 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, но он открывает проблему безопасности, когда вы дать доступ на чтение / запись нормальному пользователю к блочному устройству.

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

Теперь мне ясно, что изменение файла блочного устройства не эквивалентно изменению разрешений файловой системы и рисков, которые она создает, даже если они временны (что на самом деле может быть долгое время на сервере высокой доступности). Спасибо за подробное и четкое объяснение. — Samuel Santana, 28 July 2017 в 21:05

Thomas · Accepted Answer · 18 July 2018 в 09:40

Когда вы меняете владельца или владельца блочного устройства, вы ничего не меняете в файловой системе. Что произойдет, если вы 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, как обычный пользователь и не должен был изменять какие-либо права доступа , Все это основано на том, что у меня был доступ на чтение / запись к базовому блочному устройству. [D7] Это всего лишь простой пример, и продвинутый злоумышленник может помещать двоичный код в вашу файловую систему или обменивать известные двоичные файлы на вредоносные , Обычно используемые инструменты предварительно установлены практически для любого дистрибутива.

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

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

Thomas · Accepted Answer · 24 July 2018 в 19:24

Когда вы меняете владельца или владельца блочного устройства, вы ничего не меняете в файловой системе. Что произойдет, если вы 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, как обычный пользователь и не должен был изменять какие-либо права доступа , Все это основано на том, что у меня был доступ на чтение / запись к базовому блочному устройству. [D7] Это всего лишь простой пример, и продвинутый злоумышленник может помещать двоичный код в вашу файловую систему или обменивать известные двоичные файлы на вредоносные , Обычно используемые инструменты предварительно установлены практически для любого дистрибутива.

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

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

Elder Geek · Answer 4 · 22 May 2018 в 20:10

Я думаю, вы неправильно понимаете смысл. как член группы sudo, у вас есть доступ к R / W по умолчанию. Это не означает, что вы на самом деле корневые, просто чтобы у вас был аналогичный доступ в зависимости от того, как настроено sudo.

Дальнейшее чтение:

, как настроено sudo.

https://www.tecmint.com/su-vs-sudo-and-how-to-configure-sudo-in-linux/

1

ответ дан Elder Geek 22 May 2018 в 20:10

1

Итак, правильная интерпретация «У вас должен быть r / w доступ к файловой системе или быть root». более или менее "Вы должны использовать sudo или быть root"? – Samuel Santana 26 July 2017 в 23:14
2

@SamuelSantana IMHO, более или менее корректная, поскольку sudo по умолчанию предоставляет R / W доступ к блочным устройствам. – Elder Geek 26 July 2017 в 23:35

Elder Geek · Answer 5 · 18 July 2018 в 09:40

Я думаю, вы неправильно понимаете смысл. как член группы sudo, у вас есть доступ к R / W по умолчанию. Это не означает, что вы на самом деле корневые, просто чтобы у вас был аналогичный доступ в зависимости от того, как настроено sudo.

Дальнейшее чтение:

, как настроено sudo.

https://www.tecmint.com/su-vs-sudo-and-how-to-configure-sudo-in-linux/

Elder Geek · Answer 6 · 24 July 2018 в 19:24

Я думаю, вы неправильно понимаете смысл. как член группы sudo, у вас есть доступ к R / W по умолчанию. Это не означает, что вы на самом деле корневые, просто чтобы у вас был аналогичный доступ в зависимости от того, как настроено sudo.

Дальнейшее чтение:

, как настроено sudo.

https://www.tecmint.com/su-vs-sudo-and-how-to-configure-sudo-in-linux/

1

ответ дан Elder Geek 24 July 2018 в 19:24

1

Итак, правильная интерпретация «У вас должен быть r / w доступ к файловой системе или быть root». более или менее "Вы должны использовать sudo или быть root"? – Samuel Santana 26 July 2017 в 23:14
2

@SamuelSantana IMHO, более или менее корректная, поскольку sudo по умолчанию предоставляет R / W доступ к блочным устройствам. – Elder Geek 26 July 2017 в 23:35

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

6 ответов

Другие вопросы по тегам:

Похожие вопросы: