Проблемы безопасности, связанные с хранением секретов в сценариях
Скажем, у Вас есть программа, которую Вы хотите запустить необслуживаемый как корень, который требует секрета (такого как пароль; что-то, что Вы не хотите, чтобы другие люди узнали), который может быть считан из переменной среды. Один способ выполнить это состоял бы в том, чтобы создать сценарий как следующее и выполнить его от crontab корня.
#!/bin/bash
export SECRET='my_secret'
/usr/bin/some_program
export SECRET=
Хорошо, таким образом, я могу думать о двух проблемах безопасности здесь.
Во-первых, кто-то мог найти значение $SECRET путем чтения сценария. Используя chmod 700 должен заботиться об этом.
Во-вторых, кто-то мог использовать что-то как ps ae в то время как some_program работает. Однако, если сценарий работает как корень, только базируйтесь (или sudoers) видят его среду, правильно?
Я корректен в вере значению $SECRET может только быть найден корнем или sudoers? Есть ли другие проблемы безопасности?
И, для создания всего этого немного менее абстрактным это - то, что получило меня взгляды.
2 ответа
Действительно ли это - сценарий, который будет только когда-либо работать на Вашем собственном поле?
Современные переменные среды значений по умолчанию Linux к тому, чтобы только быть видимым для укоренения или Вы но это не портативно. Различные другие Ose или не могут отфильтровать их или не фильтруют их по умолчанию.
Мои первые мысли состояли бы в том, чтобы не экспортировать пароли в любом случае.
двуличность кажется, имеет опцию'--use-agent'это могло бы помочь здесь.
Если эта опция указана, то'
--use-agent'передается процессу шифрования GnuPG, и он выключит любое взаимодействие пароля с пользователем относительно'--encrypt-key'или'--sign-key'.
Обновление: Это мои смещенные мнения.
- Сценарий не должен заставлять информацию о безопасности экспортироваться в в среду
- Если Вы не работаете со специальным приложением (как
duplicity),
было бы легче избежать проблемы от моей предыдущей точки, просто сместившись к основанному на агенте пользователя механизму (sshимеет тот, например, и я ожидалduplicityиметь один - который это сделало), -
secretинформация лучше (в относительном смысле) защищенный с атрибутами доступа Unix в соответствии с приложением частные данные (я обращаюсь к вещам как.ssh/id_dsa)