Стратегии безопасности хранения пароля на диске
Я создаю комплект пакетных заданий, которые требуют регулярного доступа к базе данных, работая на Солярисе 10 машин. Из-за (unchangable) конструктивных ограничений мы требуемся, используют определенную программу для соединения с ним. Упомянутый интерфейс требует, чтобы мы передали незашифрованный пароль по командной строке для соединения с базой данных. Это - ужасная практика безопасности, но мы застреваем с нею.
Я пытаюсь удостовериться, что вещи правильно защищаются с нашей стороны. Так как обработка автоматизирована (т.е., мы не можем запросить пароль), и я ничего не могу сохранить вне диска, мне нужна стратегия хранения нашего пароля надежно.
Вот некоторые основные правила
- Система имеет многочисленных пользователей.
- Мы можем предположить, что наши полномочия правильно осуществляются (т.е., если файл с chmod'd к 600, это не будет публично читаемо),
- Я не возражаю против никого с доступом суперпользователя, смотрящим на наш сохраненный пароль
Вот то, что я имею до сих пор
- Пароль хранилища в password.txt
- password.txt за 600$chmod
- Процесс читает из password.txt, когда он необходим
- Буфер, перезаписанный с нулями, когда это больше не необходимо
Хотя я уверен, что существует лучший путь.
3 ответа
Это не решение для криптографии. Независимо от используемого шифра, ключ будет одинаково доступен для злоумышленника. Cyrpto не решает всех проблем.
Лучше всего использовать chmod 400, это делает его доступным только для чтения. chmod 600 - для чтения и записи, что может быть или не быть требованием. Также убедитесь, что его chown'ed предоставлен процессу, которому он нужен. Это действительно лучшее, что вы можете сделать. Даже если вы используете машину совместно с другими пользователями, они не должны иметь к ней доступ. Надеюсь, это выделенная машина, в этом случае угроза невелика. SELinux или AppArmor помогут защитить систему от межпроцессных/межпользовательских атак.
Edit: shred - это инструмент, необходимый для безопасного удаления файлов.
Edit: Основываясь на комментариях Moron/Mike, команда unix ps aux покажет все запущенные процессы и команду, используемую для их вызова. Например, следующая команда будет видна всем пользователям системы: wget ftp://user:password@someserver/somefile.ext. Безопасной альтернативой является использование библиотеки CURL. Вы также должны отключить историю командной оболочки. В bash это можно сделать, установив переменную окружения export HISTFILE=
Вы не далеки от наилучшего подхода, учитывая ваши ограничения. У вас есть две проблемы. Первый - это хранение паролей. Второй - безопасное использование пароля.
Сначала займемся вторым - у вас огромная проблема при использовании программы командной строки. Используя параметры команды «ps», пользователь может видеть аргументы, используемые при запуске программы командной строки. Судя по тому, что вы написали, это будет содержать пароль в виде обычного текста.Вы упомянули, что это неизменяемый интерфейс. Тем не менее, как этичный программист, вы должны поднять этот вопрос. Если бы это было банковское приложение для обработки финансовых транзакций, вы могли бы подумать о поиске другой работы, а не о принятии неэтичного решения.
Переходя к безопасному хранению пароля, вы не указываете, какой язык вы используете для своих командных файлов. Если вы используете сценарий оболочки, то у вас мало выхода, кроме как жестко закодировать пароль внутри сценария оболочки или прочитать его в виде обычного текста из файла. Судя по вашему описанию хранения пароля в отдельном файле, я надеюсь, что вы, возможно, пишете программу на скомпилированном языке. Если это так, вы можете сделать немного лучше.
Если вы используете скомпилированный язык, вы можете зашифровать пароль в файле и расшифровать его в своей программе. Ключ для дешифрования будет находиться в самой программе, поэтому его будет нелегко прочитать. Помимо этого, я бы
- chmod 400 файл, чтобы предотвратить его чтение другими пользователями
- , добавил префикс точки ('.') К файлу, чтобы скрыть его из обычного списка каталогов
- переименовать файл, чтобы он читать менее интересно.
- будьте осторожны, чтобы не хранить ключ в простой строке - команда 'strings' распечатает все печатаемые строки из исполняемого образа unix.
После этого следующим шагом будет улучшение управления ключами. Но я бы не стал заходить так далеко, пока не будет прояснен вопрос «ps». Нет смысла ставить третий засов на входную дверь, если вы планируете оставить окно открытым.
Не заполняйте буфер пароля нулями, это бессмысленно. Ядро может решить заменить его в произвольном месте в файле подкачки или сказать, что после выделения некоторой памяти ядро будет перемещать таблицы страниц, в результате чего другие таблицы страниц будут содержать пароль, в то время как у вас есть доступ только к новой копии.
Вы можете использовать prctl (2) с PR_SET_NAME для изменения имени процесса на лету. К сожалению, в настоящее время я не могу придумать другого способа, кроме внедрения некоторого кода в запущенный процесс через ptrace (2), что означает, что вражеские процессы будут спешить, чтобы прочитать список процессов, прежде чем вы получите возможность изменить имя нового процесса: /
В качестве альтернативы вы можете получить исправления ядра grsecurity и включить CONFIG_GRKERNSEC_PROC_USER:
Если вы здесь скажете Y, пользователи без полномочий root будут иметь возможность просматривать только свои процессы, и ограничивает их от просмотр сетевой информации, и просмотр символа ядра и модуля Информация.
В результате ps не сможет просматривать выполняемую команду, поскольку ps читает из / proc /
Указанный интерфейс требует от нас пройти простой текстовый пароль поверх команды линия для подключения к базе данных. Этот ужасная практика безопасности, но мы застряли в этом.
Это плохая практика безопасности из-за проблем в архитектуре операционной системы. Ожидаете ли вы, что другие пользователи смогут перехватывать ваши системные вызовы? Я бы не стал винить разработчика, который попал в эту ловушку.