Что делать с конфиденциальными данными в bash-скрипте?

[virusoft]

Виктор Дубосарский,
Я думаю что читать и выполнять это все таки разные вещи.
=============
Однако должен признаться что я был не прав. Без чтения скрипт не выполняется. Только что проверил.

[Виктор Дубосарский]

Я думаю что читать и выполнять это все таки разные вещи.

virusoft,
Для бинарников это так, но для скриптов аттрибуты rx зависимые вещи. В чем легко убедиться, написав простейший скрипт "hello, world". Подробнее см. тут http://www.grymoire.com/Unix/Permissions.html

If the file is a shell script, then the execute attribute says you can treat it as if it were a program. To put it another way, you can create a file using your favorite editor, add the execute attribute to it, and it "becomes" a program. However, since a shell has to read the file, a shell script has to be readable and executable. A compiled program does not need to be readable.

[Azure]

Обычная практика:
логин:пароль записывают в отдельный файл c разрешённым чтением только от рута.
Скрипт запускают через sudo.
В настройках visudo (/etc/sudoer) прописывают пользователю(ям) безпарольный запуск скрипта.

[alsoijw]

Azure, скрипт надо защитить от подмены/изменения.

[Виктор Дубосарский]

Обычная практика:
логин:пароль записывают в отдельный файл c разрешённым чтением только от рута.
Скрипт запускают через sudo.
В настройках visudo (/etc/sudoer) прописывают пользователю(ям) безпарольный запуск скрипта.

Это самое простое решение из предложенных, спасибо.

[Azure]

Azure, скрипт надо защитить от подмены/изменения.

Согласен, важно.

[alsoijw]

Для бинарников это так, но для скриптов аттрибуты rx зависимые вещи.

Так изготовь бинарник.

[Виктор Дубосарский]

Так изготовь бинарник.

Согласен, тоже хороший вариант. Спасибо.

Подведу итог найденных решений:
1. Отдельный текстовый файл с логин/паролями + скрипт, работающий через sudo.
2. Бинарник -r+x с зашитой в него командой.
3. Автоматическое получение пароля из консоли у менеджера через stdout или буфер обмена (GnomeKeyring, KeePassX, Vault).

[AnrDaemon]

Только не забудьте, что такие вещи
1. надо писать в sudoers.d/
2. редактировать через visudo

[kobaltd]

Долго читал ветку и вникал - сейчас попробую сформулировать: ключ/пароль в данном случаи это "средство" для доступа к "закрытой" информации - т.е. цель защитить инфу от "чужих", а не сам "пароль". Далее использование какого либо средства "дать пользователю пароль"/"скрипт или бинарник дающий доступ"/"централизованное хранение"/т.д. - это аннулирует все потуги в этом направлении - т.к. основная задача в данном случаи не выполняется - и без разницы будет "знать" пользователь пароль или будет иметь "файлик" который знает этот "пароль" или будет иметь "доступ" к ОП которое имеет этот пароль -  смысл тот же самый - пользователь имеет "средство" для доступа к этой инфе, и без разницы знает он этот пароль или не знает. Мне кажется данная проблема должна вообще решаться в другой "плоскости", к которой у пользователя нет доступа. А так - какая разница, знает пользователь 20 символов или имеет на руках бинарник который знает эти символы и т.д., даже если он не может его прочитать - он все равно может его запустить и тем самым получить доступ и т.д. - По сути проблема осталось прежней - если пользователь может "попасть" в "систему" он имеет доступ зная пароль или не зная, и теперь утечка пароля из 20 символов от "зашифрованной инфы" меняется на утечку пароля из 1-8 символов (в среднем) от учетки пользователя.
Имхо - данная проблема должна решаться в принципе по другому, без передачи пользователю чего либо, что будет являться "ключом" к информации.

[Valan]

обфускация скрипта. http://habrahabr.ru/post/139666/

[AnrDaemon]

Valan, спасибо, поржал.

[alsoijw]

Valan, и?

[Valan]

Valan, и?

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

[salvador]

Есть желание автоматически без ввода пароля монтировать шифрованную файловую систему encfs через bash-скрипт из под пользователя. Команда простая:

Код: [Выделить]

$ echo mylongcoolpassword | encfs -S /home/user/encrypted /home/user/unencrypted
Очевидный и ужасный недостаток такого скрипта - наличие открытого назащищенного пароля. Что можно по этому поводу предпринять?

1. Можно ли сделать так, чтобы в скрипте открытый пароль не указывался, а вместо этого пароль каким-то чудесным и безопасным образом импортировался из защищенного хранилища, к которому имеет доступ (на запись) только системный администратор?
2. Куда положить и как правильно настроить права доступа к bash-скрипту, содержащему конфиденциальные данные так, чтобы максимально ограничить доступ к нему? В идеале хотелось бы, чтобы просматривать и изменять скрипт мог только root, но запускаться скрипт должен из под пользователя. Как этого добиться?

Добрый день!
Автор, у вас неправильный подход к организации хранения зашифрованной информации. Оттого и все проблемы.
Вам нужно менять или систему хранения в целом, или использовать пароль более запоминающийся.
Если хранить пароль в открытом виде в скрипте - то можно и не шифровать диск