Передача пароля в командной строке (дочернему процессу, запущенному из моей программы), как известно, небезопасна (потому что его могут увидеть даже другие пользователи с помощью команды ps). Можно ли передавать его как переменную среды?
Что еще я могу использовать, чтобы передать его? (За исключением переменной среды) кажется, что самое простое решение - использовать канал, но это самое простое решение - нелегкое.
Я программирую на Perl.
environment-variables
fork
ipc
Porton
источник
источник
Ответы:
Аргументы процесса видны всем пользователям, но среда видна только одному и тому же пользователю ( по крайней мере, в Linux , и я думаю о каждом современном варианте Unix). Поэтому передача пароля через переменную среды безопасна. Если кто-то может читать переменные вашей среды, он может выполнять процессы как вы, так что игра уже окончена.
Содержимое среды подвержено некоторому риску косвенной утечки, например, если вы запускаете
ps
что-то для исследования и случайно копируете результат, включая конфиденциальные переменные среды, в публичном месте. Другой риск заключается в том, что вы передаете переменную среды программе, которая в ней не нуждается (включая дочерние элементы процесса, которому требуется пароль), и эта программа предоставляет свои переменные среды, потому что она не ожидала, что они будут конфиденциальными. Насколько серьезны эти риски вторичной утечки, зависит от того, что делает процесс с паролем (как долго он работает? Он запускает подпроцессы?).Проще убедиться, что пароль не будет случайно утек, передав его по каналу, который не предназначен для прослушивания, например по каналу. Это довольно легко сделать на отправляющей стороне. Например, если у вас есть пароль в переменной оболочки, вы можете просто сделать
если
theprogram
ожидает пароль на его стандартный ввод. Обратите внимание, что это безопасно, потому чтоecho
является встроенным; это не будет безопасно с внешней командой, так как аргумент будет представлен вps
выводе. Еще один способ добиться того же эффекта - вот документ:Некоторым программам, которым требуется пароль, может быть предложено прочитать его из определенного дескриптора файла. Вы можете использовать дескриптор файла, отличный от стандартного ввода, если вам нужен стандартный ввод для чего-то другого. Например, с
gpg
:Если программе нельзя сказать, чтобы она читала из файлового дескриптора, но можно было бы сказать, чтобы она читала из файла, вы можете сказать ей, чтобы она читала из файлового дескриптора, используя имя файла, например `/ dev / fd / 3.
В ksh, bash или zsh вы можете сделать это более кратко с помощью подстановки процессов.
источник
/usr/ucb/ps
версиях был установлен root, поэтому он мог читать и отображать переменные окружения других процессов - это было удалено в Solaris 10, поэтому приведенный выше ответ «каждый второй современный вариант Unix» относится к выпускам Solaris 2005 и более поздних версий.Вместо передачи пароля напрямую через аргумент или переменную окружения
используйте тот же аргумент или переменную среды для передачи имени файла :
Затем вы можете передать либо разрешение защищенного обычного файла (хотя это не защитит вас от других процессов , работающих под тем же пользователем), или
/dev/stdin
и труба его в (который AFAIK защитит вас от других процессов , запущенных под тем же пользователем):Если вы используете
/dev/stdin
здесь, обязательно, что это труба . Если это терминал, он будет доступен для чтения другим процессам, работающим под тем же пользователем.Если вам уже нужно использовать ваш
/dev/stdin
для чего-то другого, вы можете использовать подстановку процесса, если вы находитесь в оболочке, которая его поддерживает, что по сути эквивалентно использованию каналов:Именованные каналы (FIFO) могут выглядеть так же, как они, но они приемлемы.
Эти решения также не совсем безопасны , но они могут быть достаточно близки, если вы не находитесь в системе с ограниченным объемом памяти, которая сильно меняется.
В идеале вы должны читать эти файлы (pipe - это тоже файл) в память, помеченную mlock (2) как не подлежащую удалению, что обычно делают такие программы обработки паролей, как gnupg.
Примечания:
Передача номеров файловых дескрипторов теоретически так же хороша, как и файл, как передача имен файлов, но имена файлов более практичны, потому что
<()
дает вам имя файла, а не номер дескриптора файла (иcoproc
s дает вам файловые дескрипторы , помеченные как FD_CLOEXEC , что делает эти файловые дескрипторы непригодными в этом контексте).Если вы работаете в системе Linux с
/proc/sys/kernel/yama/ptrace_scope
установленным значением0
, тогда AFAIK, нет никакого пуленепробиваемого способа защитить себя от других процессов, запущенных под тем же пользователем (они могут использовать ptrace для подключения к вашему процессу и чтения вашей памяти)Если вам нужно только сохранить свой пароль от процессов, запущенных под разными (не-root) пользователями, тогда подойдут аргументы, переменные среды, каналы и файлы, защищенные разрешениями.
источник
Нет, переменные окружения тоже легко читаются и попадают в дочерние процессы. передать его с помощью трубы.
источник
ps
и/proc
можно увидеть.ptrace()
указать цель и прочитать ее память.Если больше ничего не подходит, рассмотрите службу хранения ключей Linux (цепочки ключей ядра).
Начните с: security / keys.txt . Одна из цепочек ключей по умолчанию может быть клонирована между родительским и дочерним процессами.
Это не самое простое решение, но оно существует и, похоже, поддерживается и используется (оно также было связано с ошибкой Android в прошлом году).
Я не знаю о его «политическом» статусе, но у меня была аналогичная потребность, и я начал работать над привязкой Guile. Не сталкивался с уже существующей поддержкой Perl.
источник