Находятся ли читаемые / записываемые / исполняемые ссылки в дырах в безопасности / usr / bin?

Question

% ls -l /usr/bin/edit                                                                                                
lrwxrwxrwx 1 root root 3 Jan 10 05:54 /usr/bin/edit -> vim*

Похоже, что это применимо ко многим двоичным файлам в update-alternatives , по крайней мере, в Suse и, возможно, в других дистрибутивах Linux. Не означает ли это, что любая скомпрометированная учетная запись в Suse может изменить символическую ссылку, обманывая пользователя в выполнении чего-либо? Если так, почему это разрешения по умолчанию?

Answer 1

Из записи в Википедии по Symbolic link:

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

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

# ln -s /bin/ls blah
# ls -la blah
lrwxrwxrwx 1 root root 7 Fev 28 15:07 blah -> /bin/ls
$ rm blah
rm: cannot remove `blah': Operation not permitted
$ ln -s blah /bin/true
ln: failed to create symbolic link `/bin/true': File exists

Answer 2

Одним словом, нет.

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

Возьмем пример view => vim (общий симлинк в / USR / бен, вызовите vim По view имя , и он будет открыть текстовый файл только для чтения).

Ядро откроет view , увидит, что это указатель на vim, закроет view и затем откроет vim . Когда он открывает /exec vim, он использует все проверки безопасности в vim . Таким образом, vim все еще открыт с разрешениями на vim, чего вы и ожидаете.

Ах, ха! Но символическая ссылка представляет собой файл, и если он доступен для записи, я могу открыть его, отредактировать и изменить цель! /usr /bin /view становится указателем на /tmp /myevilexec. Одним словом, нет. Это специальный файл, вы не можете открыть символическую ссылку 'file' и отредактировать его таким образом. Вы можете заменить только символическую ссылку, и тогда права доступа на символическую ссылку не имеют значения - каталог разрешений определяет, можете ли вы удалять файлы / создавать новые файлы.

Короче говоря, 777 для символических ссылок не является брешей в безопасности, и это делает персики символьных ссылок «невидимыми», а фактически перми являются целевым файлом, чего вы и ожидаете.

Answer 3

отвечая на собственный вопрос после выяснения:

Я понял это. Это будет дырой в безопасности, за исключением того факта, что /usr/bin принадлежит root и не доступна для записи всем, и поэтому вы не можете изменить ссылку. Если бы /usr/bin был доступен для записи во всем мире, вы могли бы заменить ссылку своей собственной ссылкой, но это не так.

В качестве доказательства концепции:

% cd
% sudo touch rootfile
% sudo ln -s rootfile rootfile_link
% touch evilfile
% ln -s evilfile evilfile_link

# works, but only if directory permissions are correct:
% cp evilfile_link rootfile_link

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

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