Вот вопрос, который я не могу найти хорошо ответьте на.
В Windows / DOS нас «учили», что можно использовать возможность запускать программы из текущего каталога без необходимости указывать путь к префиксу.
Однако поведение по умолчанию для Linux таково, что вы должны использовать префикс ./ для приложений / скриптов в текущем каталоге.
Люди говорят, что разрешать выполнение программ / сценариев без префикса каталога - плохая практика безопасности. Есть много «плохих методов безопасности», но этот не имеет для меня смысла. Например, я не собираюсь заходить в каталог / some / unamiliar / и запускать программы вроде ls. Я бы cd (чтобы попасть в мой домашний каталог), затем набрал ls -la / some / unamiliar / directory. Конечно, в плохой день я бы сделал это.
Я вижу «угрозу», если кто-то помещает программу с именем ls в каталог, а плохой системный администратор записывает в этот каталог и запускает ls от имени пользователя root, а ls добавляет пользователя бэкдора и другие злые вещи. Хорошо. Но обычно в этом случае пользователь будет жаловаться: «Ой, не работает, вы можете это проверить?». Я бы sudo su "user" и попробовал ls в качестве него.
Если я чего-то полностью не упускаю, добавляю "." к вашему PATH действительно так плохо?
Редактировать:
Все ответы на данный момент подходят для указания на риски безопасности, однако все упускают аргументы в пользу Windows. Под Windows текущий каталог НЕ находится на вашем пути, поэтому нет возможности отключить возможность просто запустить program.exe afaik. Однако командная строка допускает возможность добавления к команде префикса. \ (. \, Похоже, работает, однако вы должны использовать \, иначе вы можете получить какую-то escape-последовательность). Под Windows всегда ли мы должны префикс команды? Кроме того, должны ли мы связаться с Microsoft и сказать им, что они плохо внедряют такое ожидаемое поведение?
Мой опыт работы с Windows, поэтому я предвзято ожидаю, что программы в текущем каталоге смогут запускаться, хотя я знаю, что в мире Unix это не так. Вот почему я поставил вопрос там.
Расширить то, что я имею в виду под «плохими методами безопасности» (и почему они заключены в кавычки), заключается в том, что мы могли бы сослаться на миллионы, если не миллиарды, методов обеспечения безопасности, которые люди ДОЛЖНЫ выполнять ... но мы этого не делаем, и если бы мы это сделали , человек обязательно сойдет с ума. Должны ли мы снизить все риски безопасности, которые могут помешать работе пользователя? Я говорю «нет», но это потому, что я считаю, что безопасность должна быть прозрачной для пользователей, но мне нравится первое предложение Хауса в его ответе «Как и все остальное, это мышление». И я думаю, что мы должны оставить все как есть.
Как и все остальное, это образ мышления.
Имея текущий каталог как часть вашего пути, вы действительно увеличиваете свой риск. Тот факт, что троянская программа была запущена, не означает, что она не будет делать то, что от нее можно ожидать. Другими словами, если использовать ваш пример ls, троянская программа, если она не была разработана тупицей, действительно предоставит вам список каталогов, который вы запрашивали, так что, если вы не скажете, что файл находится там, у вас не было бы причин ожидать, что что-то пошло не так (возможно, было бы разумно решить удалить себя из предоставленного списка каталогов, чтобы еще больше снизить вероятность обнаружения).
Для этого это будет означать, что кто-то уже проник в данную систему до такой степени, что может разместить файлы в вашей файловой системе. Таким образом, вы уже находитесь в плохом положении, но еще есть возможности для того, чтобы стать хуже.
Как правило, я не помещаю текущий каталог на свой путь в моих системах linux / unix, и это не составляет большого труда. Когда я пишу программу или сценарий, которые хочу часто использовать, я помещаю их в папку, расположенную на моем пути, и ограничиваю права на запись для указанного файла.
Короткий ответчик, добавление текущего каталога к вашему пути приведет к гибели непривилегированного пользователя, скорее всего, нет, но зачем рисковать?
Для root НЕ ДЕЛАЙТЕ ЭТОГО.
Для рута смертельно опасно. Другим пользователям по этой причине я бы рекомендовал не добавлять "." пути (а также безопасности) заключается в том, что это приведет вас к странным и запутанным проблемам, например что процессы, которые ищут путь, могут начать занимать очень разное время или найти другую программу с тем же именем. Например, / usr / ucb в Solaris содержит версию BSD команды ps. Создайте новую файловую систему и заполните ее огромным количеством файлов, а затем укажите "." на вашем пути попробуйте выполнить завершение bash для "grep". Это займет больше времени, потому что. нужно искать, а там миллион файлов. "." также может быть на каком-то мучительно медленном носителе, например, на очень удаленном монтировании NFS или что-то подобное. Вы можете уйти от этого и никогда не увидеть, что это вызывает проблему, но когда это действительно вызывает проблему, может быть не сразу очевидно, какова основная причина. В далеком прошлом я видел много проблем с производительностью, вызванных очень длинными PATH, PATH не одинаковыми в разных средах и так далее. My 2D: на вашей коробке с вашим собственным пользователем, дерзайте, если это облегчает жизнь. При производстве не допускайте попадания точки на пути.
Как уже упоминалось, наиболее очевидная угроза безопасности - это просто наличие некоторого вредоносного кода в текущем каталоге, который заменяет существующий исполняемый файл. Возможно ли это использовать или нет, на самом деле зависит от того, насколько строго вы соблюдаете политику «Не запускать команды из непроверенного каталога».
Однако может возникнуть более тонкая и потенциально более серьезная проблема, заключающаяся в том, что разрешение команд больше не предсказуемо. Например, если вы привыкли использовать runcommand просто набрав runc<tab> в BASH это будет работать в большинстве каталогов, но не удастся, если вы просто окажетесь в каталоге с исполняемым файлом runcom. Опять же, это можно обойти, просто зная, что именно вы делаете, но по моему опыту после ввода runc<tab> пятьдесят раз без проблем, пятьдесят первый раз может легко ускользнуть из поля зрения.
Раздражает то, что в этом нет злого умысла. В вашей системе нет вирусов, нет троянов, тайно внедряемых в ваш домашний каталог. Это всего лишь две разные команды в двух разных каталогах, которые делают две разные вещи. runcom вполне законно может потребоваться просто удалить половину файлов из вашего домашнего каталога, но это не значит, что вы хотите запустить его случайно.
Это может быть еще более опасно, если вы имеете дело со скриптами. Если вы запустите типичный сценарий оболочки из командной строки, он примет вашу переменную $ PATH. Как и в приведенном выше примере, это означает, что поведение сценария может отличаться, если вы запускаете его из разных каталогов. Вы можете запустить другую версию любой данной команды, если вы, скажем, /usr/bin вместо использования /usr/local/bin версия. Или, в качестве альтернативы, вы можете в конечном итоге иметь доступные команды, которые обычно сигнализируют о законной ошибке при отсутствии - одна из немногих вещей хуже, чем неожиданный сбой важного сценария, - это неожиданный сбой сценария и мышление это удалось. Хорошо написанные сценарии обходят это, либо устанавливая свой собственный $ PATH, либо явно вызывая команды, которым предшествует полный путь.
Не все сценарии хорошо написаны.
Многие из этих проблем можно решить, просто установив текущий каталог в качестве последней точки разрешения в пути вместо первого (PATH=$PATH:. скорее, чем PATH=.:$PATH), но это все же не идеальное решение. Видя как явный префикс команды с ./ в любом случае, чтобы запустить версию из локального каталога, нужно всего лишь два дополнительных нажатия клавиш, я буду придерживаться этого.
Умные атаки, хотя, вероятно, и редкие, могут сочетать несколько методов, начиная с непривилегированной среды с использованием поддельного исполняемого файла в "." ПУТЬ текущего каталога, чтобы вставить псевдоним в среду, используя технику, аналогичную моему вопросу / ответу Вот который последует за вами в привилегированную среду.
cd и запускает вредоносное ПО, думая, что оно выполняет свою удобную программуsu написав пользователю ~/.bashrcalias su='sudo bash --rcfile /path/to/badrc'su - и получает приглашение оболочки и начинает использовать команды с псевдонимом "badrc" с использованием методов скрытого псевдонимаЭто, безусловно, запутанная последовательность, возможны и другие варианты, но зачем оставлять себя открытым? Отсутствие точки на вашем пути (плюс жесткий контроль над sudoers и поддержание хороших привычек) поднимает планку для злоумышленников.
Наряду с pwd на медленной удаленной файловой системе возникает проблема: если. по какой-то причине больше не существует, вы больше не можете запускать команды, кроме встроенных команд оболочки, что очень сбивает с толку. Возможно, pwd был удален, файловая система, содержащая его, могла быть принудительно отключена, или на сервере, который был выключен.