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