Вопросы Теги

Как передать пароль дочернему процессу?

Попробуйте

df -h | sed 's / [\ t] /, / g'

или

df -h | sed 's / [ \ t] /, / g '

18
16.07.2016, 14:12
4 ответа

Аргументы процесса видны всем пользователям, но среда видна только одному пользователю ( по крайней мере в Linux , и я думаю, что в каждом современном unix вариант). Таким образом, передача пароля через переменную среды безопасна.Если кто-то может читать переменные вашей среды, он может выполнять процессы как вы, так что игра уже окончена.

Содержимое среды имеет некоторый риск косвенной утечки, например, если вы запустите ps , чтобы что-то исследовать, и случайно скопируйте и вставьте результат, включая конфиденциальные переменные среды, в общественное место. Другой риск заключается в том, что вы передаете переменную среды программе, которая в ней не нуждается (включая дочерние элементы процесса, которому нужен пароль), и эта программа раскрывает свои переменные среды, поскольку не ожидала, что они будут конфиденциальными. Насколько серьезны эти риски вторичной утечки, зависит от того, что делает процесс с паролем (как долго он выполняется? Запускаются ли подпроцессы?).

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

echo "$password" | theprogram

, если программа ожидает пароль на стандартном входе. Обратите внимание, что это безопасно, потому что echo является встроенным; это было бы небезопасно с внешней командой, так как аргумент будет показан в выводе ps . Другой способ достичь того же эффекта - использовать здесь документ: 

theprogram <<EOF
$password
EOF

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

get-encrypted-data | gpg --passphrase-fd 3 --decrypt … 3<<EOP >decrypted-data
$password
EOP

Если программе нельзя приказать читать из файлового дескриптора, но можно сказать, что она должна читать из файла, вы можете указать ей читать из файлового дескриптора, используя имя файла, например / dev / fd / 3. 

theprogram --password-from-file=/dev/fd/3 3<<EOF
$password
EOF

В ksh, bash или zsh это можно сделать более кратко, заменив процесс. 

theprogram --password-from-file=<(echo "$password")
27
27.01.2020, 19:45

Если ничего другого не подходит, рассмотрите службу хранения ключей Linux (связки ключей ядра).

Начать с: security / keys.txt . Один из ключей по умолчанию может быть клонирован между родительским и дочерним процессами.

Это не самое простое решение, но оно существует и, похоже, поддерживается и используется (в прошлом году оно также было связано с ошибкой Android).

Я не знаю его «политический» статус, но у меня был аналогичная потребность, и начал работать над привязкой Guile. Не встречал ранее существовавшей поддержки Perl.

1
27.01.2020, 19:45

Вместо передачи пароля непосредственно через аргумент или переменную окружения

#!/bin/bash
#filename: passwd_receiver
echo "The password is: $1"

используйте тот же аргумент или переменную окружения для передачи имени файла: 

#!/bin/bash
#filename: passwd_receiver
echo "The password is: $(< "$1")"

Тогда вы можете передать либо защищенный правами обычный файл (хотя это не защитит вас от других процессов, запущенных под тем же пользователем), либо /dev/stdin и pipe (что, AFAIK, защитит вас от других процессов, запущенных под тем же пользователем): 

 echo PASSWORD | ./passwd_receiver /dev/stdin

Если вы используете /dev/stdin здесь, обязательно, чтобы это был pipe. Если это терминал, он будет доступен для чтения другим процессам, запущенным под тем же пользователем.

Если вам уже нужно использовать ваш /dev/stdin для чего-то другого, вы можете использовать замещение процесса, если вы находитесь в оболочке, которая поддерживает его, что по существу эквивалентно использованию труб:

./passwd_receiver <(echo PASSWORD)

Именованные трубы (FIFO) могут выглядеть как одно и то же, но они взаимозаменяемы.

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

В идеале, вы должны читать эти файлы (pipe - это тоже файл) в память, помеченную mlock(2) как не подлежащую замене, что обычно и делают программы работы с паролями, такие как gnupg.

Примечания:

  1. Передача номеров файловых дескрипторов теоретически так же хороша, как и передача имен файлов, но имена файлов более практичны, потому что <() дает вам имя файла, а не номер файлового дескриптора (а coprocы дают вам файловые дескрипторы, помеченные FD_CLOEXEC, что делает эти файловые дескрипторы непригодными в данном контексте).

  2. Если вы работаете в системе Linux, где
    /proc/sys/kernel/yama/ptrace_scope имеет значение 0, то AFAIK, нет надежного способа защиты от других процессов, запущенных под тем же пользователем (они могут использовать ptrace для подключения к вашему процессу и чтения вашей памяти)

  3. Если вам нужно только держать ваш пароль подальше от процессов, запущенных под другими (не root) пользователями, то подойдут аргументы, переменные окружения, трубы и файлы с защитой прав доступа.

10
27.01.2020, 19:45

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

7
27.01.2020, 19:45

Теги

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