передача пароля через коммандную строку

Sorry за форматирование - копировал из одного окна Lynx в другое ;-)

> Sorry за форматирование - копировал из одного окна Lynx в другое

в lynx'e можно удобно редактировать формы: ctrl-x e жмешь, и ты в редакторе.

> Sorry за форматирование - копировал из одного окна Lynx в другое >> в lynx'e можно удобно редактировать формы: ctrl-x e жмешь, и ты в редакторе. >> dilmah * * (*) (15.06.2004 14:15:15) ========= супер! Кстати если выбрать не форму - то пишет, что пока не может редактировать HTML удаленно :-)

А по сабжу есть у кого идеи?

а чем тебя не устраивает хранить пароль в файле? ИМХО, нужно по любому, использовать какой-то внешний источник.

пароли же всегда реально хранятся в файлах -- типа .ssh/* или .gnupg/*

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

Запрети юзверям через ps смотреть чужие процессы и будет тебе счастье.

А во вторых кто тебе сказал что его в ps видно? Если ты скриптом это делать собрался.

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


Делается это так при чтении параметров командной строки читаем пароль и тут же записываем в *argv вместо пароля ХХХ или любую последовательность символов не длинее полученого пароля.

Например


else if (!strcmp(*argv, "-sp") || !strcmp(*argv, "--sql-user-password")) {
if (!(*++argv)) usage();
else {
int i=0;
if((sql_user_password=strdup(*argv))==NULL) {
printf("cant init sql-username-password"); exit(-1);
}


while((*(*argv+i)) != '\0') {
*(*argv+i)='X';
i++;
}
}

argc--;

При этом ps в параметрах командной строки будет показывать ХХХХ вместо пароля.

PS: имеет смысл задать данный вопрос в форуме по программированию.

экспортировать переменную среды в bash потом ее убивать

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

За один проход это не сделать - значит придется или по десять раз вводить пароль для расшифровки "мастер-файла", или создавать временный файл, где хранить эту извлеченную информацию в открытом виде, да еще как-то передавать ее через командную строку другим программам.

Нужно что-то типа программы "Password safe", только в консольном виде, с возможностью передавать извлеченные пароли(ключи) другим программам. В некоторых программах это уже реализовано в готовом и относительно безопасном виде (loopAES имеет режим "multikey" с возможностью извлечения симметричных ключей, из файла, зашифрованного GPG).

Но была инфа, например в книге "Linux hacking exposed", что можно исхитриться это сделать в обычных консольных программах, надо для передачи пароля использовать именованные каналы и еще что-то там.

В общем, люди это как-то делают, неужели слабо это сделать из ком. строки? (Ведь с помощью нее можно сделать почти все)

> А во вторых кто тебе сказал что его в ps видно? Если ты скриптом это делать собрался.

Да говорят, все равно как-то увидеть можно.

> Экспортировать переменную среды в BASH и убивать.

А что это даст? невозможность просмотреть значения переменных? Пример можно? Поиск темы "password trought command line" ничего полезного не дает.

> экспортировать переменную среды в bash потом ее убивать

где-то читал что в некоторых Юниксах с помощью ps можно и окружение процессов смотреть.

> За один проход это не сделать - значит придется или по десять раз вводить пароль для расшифровки "мастер-файла", или создавать временный файл, где хранить эту извлеченную информацию в открытом виде, да еще как-то передавать ее через командную строку другим программам.

ну сделай 10 fifo: f0..f9

а потом: password -> | tee f0 | tee f1 | ... | tee f9 | code

И считывай себе свои пароли из f0 .. f9

Но непонятно чем это лучше файла? Если у тебя своп не шифруется, то содержимое пайпа в любом случае может попасть в своп. Если же своп шифруется, то чем это лучше файла в mfs/tmpfs??

>Но непонятно чем это лучше файла? Если у тебя своп не шифруется, то содержимое > пайпа в любом случае может попасть в своп. Если же своп шифруется, то чем это > лучше файла в mfs/tmpfs??

И своп шифруется и tmpfs, ну и что? перезагрузка редко происходит. Временно открывать /dev/shm тоже неудобно, хорошо бы все как-то через pipe/fifo

> хорошо бы все как-то через pipe/fifo

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

>ну так я же написал -- делаешь mkfifo кучу пайпов. Считываешь с клавиатуры один > раз пароль, загоняешь его с помощью tee во все эти пайпы. Потом используешь их.

Кажись, это самое очевидное решение, спасибо, попробую...

Может это в security FAQ включить?

> Считываешь с клавиатуры один > раз пароль, загоняешь его с помощью tee во все эти пайпы.

Так! Еще вопросик read -s passw ; echo $passw | tee fifo_f1 > fifo_f2

Тоже не катит! Из echo пароль будет виден через ps! Да еще tee все предательски отображает на экране! Нужен какой-то прямой ввод с терминала ( dd if=/dev/tty | tee ... ) В общем надо как-то сделать без переменных! И желательно без отображения на экран.

(date | tee pipe1 | tee pipe2) > /dev/null

Вот таким путем только что убрал вывод с экрана через tee!

Осталось только прикрутить прямой ввод с клавы на pipe...

Осталось совсем чуть-чуть: надо или читать пароль с клавы прямо в пайп или в файл fifo! Лучше в |

> прямо в пайп или в файл fifo! Лучше в |

дык то что создает mkfifo ничем не отличается от того что создает шелл когда ты пишешь |

> то что создает mkfifo ничем не отличается от того что создает шелл когда ты пишешь |

наличием имени отличается

> Если передавать параметры в командной строке то нет выбора. процедура стандартная

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

В общем тот кто сможет обощить и нормальным языком написать параграф по этой теме, можно включить в FAQ. Текст присылать ivlad /at/ unixgods.net

dialog --stdout --passwordbox "input" 0 0 1>file

Можно Xdialog - тогда удобнее запускать в фоне (если конечно есть Иксы).

> Из echo пароль будет виден через ps!

Вообще-то, echo - встроенная команда и в ps будет bash, а не echo.

#!/bin/sh
read -s -p "Password: " passwd
cat fifo1 |tee fifo2 |tee fifo3 >fifo4 &
cat >fifo1 <<EOF
$passwd
EOF

$ cat fifo2& cat fifo3& cat fifo4&
$ sh script.sh

>Вообще-то, echo - встроенная команда и в ps будет bash, а не echo.

А мы перестраХУЕМся :-)

Точно не видно будет?

А переменную $passwd никто случаем не перехватит?

Может лучше прямо в пайп через dialog-passwordbox? Если сохранять в переменной то и куча пайпов не нужна - засылай прямо из нее столько раз, сколько надо и куда хочешь хоть через один пайп.

> Точно не видно будет?

Хм... У меня под рукой нет стандарта POSIX, поэтому я не знаю, является ли эта команда _по_стандарту_ встроенной в shell или может быть внешней. Во всяком случае:

$ which echo
/bin/echo

Но bash не использует /bin/echo, если ему специально не сказать, т.к. у него встроенная есть, а её точно видно не будет.

> А переменную $passwd никто случаем не перехватит?

Если не приаттачится gdb и не залезет прямо в память bash'а, то нет. А если он это сможет сделать, то есть более другие и простые способы стырить пароль. Элементарным keyboard spy, например.

> Может лучше прямо в пайп через dialog-passwordbox?

dialog есть не везде.

> Если сохранять в переменной то и куча пайпов не нужна - засылай прямо из нее столько раз, сколько надо и куда хочешь хоть через один пайп.

Абсолютно точно. При условии, что достоверно известно, что echo - встроенная. Хотя, можно и функцию написать:

#!/bin/sh
do_echo()
{
cat <<EOF
$@
EOF
}
do_echo Hello, world\!

Тоже фиг перехватишь.

Я к примеру в скриптах bash пароль для openssl передаю через переменную среды
а получаю через kdialog
он (openssl) прекрасно их понимает т.к. предусмотренно опционально
ее (значение где пароль) видно только для этого процесса, да и убить ее можно в конце скрипта.

> пароль для openssl передаю через переменную среды

А теперь попробуй:
$ cat /proc/$$/environ |tr "\0" "\n"

И подумай, чем это грозит твоим скриптам :)

Кажется, самый безопасный вариант с кучей fifo и переназначением файлового дескриптора на эти fifo по очереди для чтения.

Тотже gpg умеет читать пароль из дескриптора (ну оттуда, откуда он это указывает).

А вообще, неужели этот веломипед (subJ) никто не изобрел еще?

s/веломипед/велосипед

>А теперь попробуй: 
>$ cat /proc/$$/environ |tr "\0" "\n" 
> 
>И подумай, чем это грозит твоим скриптам :)

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

в четвертых пароль свой я так и не увидел ;)

> только хозяин имеет право читать.

Хм... Действительно. Я грешным делом подумал, что как и /proc/<pid>/cmdline она world-readable. Тогда всё должно быть в порядке.