Стратегии безопасности для хранения пароля на диске

Question

Я создаю набор пакетных заданий, требующих регулярного доступа к базе данных, на компьютере Solaris 10. Из-за (неизменяемых) конструктивных ограничений нам необходимо использовать определенную программу для подключения к ней. Указанный интерфейс требует, чтобы мы передавали простой текстовый пароль через командную строку для подключения к базе данных. Это ужасная практика безопасности, но мы застряли с ней.

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

Вот несколько основных правил

1. В системе несколько пользователей.
2. Мы можем предположить, что наши разрешения применяются должным образом (то есть, если файл с chmod'd до 600, он не будет публично читаемым)
3. Я не против того, чтобы кто-нибудь с правами суперпользователя смотрел на наш сохраненный пароль

Вот что у меня так далеко

• Сохранить пароль в password.txt
• $ chmod 600 password.txt
• Процесс читает из password.txt, когда это необходимо
• Буфер перезаписывается нулями, когда он больше не нужен

Хотя я уверен, что есть лучший способ.

Answer 1

Это не решение для криптографии. Независимо от используемого шифра ключ будет одинаково доступен атакующему. Кирпто не решает всех проблем.

chmod 400 лучше, это делает его доступным только для чтения. chmod 600 - чтение-запись, что может или не может быть требованием. Также удостоверьтесь, что он определен процессом, который нуждается в этом. Это действительно лучшее, что вы можете сделать. Даже если вы делитесь машиной с другими пользователями, они не смогут получить к ней доступ. Надеюсь, это выделенная машина, в этом случае угрозы не так много. SELinux или AppArmor помогут защитить систему от межпроцессных / межпользовательских атак.

Edit: shred - инструмент, необходимый для безопасного удаления файлов.

Редактировать: На основании комментариев Морон / Майка команда unix ps aux отобразит все запущенные процессы и команду, использованную для их вызова. Например, следующая команда будет доступна всем пользователям системы: wget ftp://user:password@someserver/somefile.ext. Безопасной альтернативой является использование библиотеки CURL. Вы также должны отключить свою историю снарядов. В bash вы можете сделать это, установив переменную окружения export HISTFILE=

Answer 2

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

Сначала разберитесь со вторым - у вас огромная проблема в использовании программы командной строки. Используя параметры команды ps, пользователь может видеть аргументы, используемые при запуске программы командной строки. Из того, что вы написали, это будет содержать пароль в виде простого текста. Вы упоминаете, что это неизменный интерфейс. Тем не менее, как этический программист, вы должны поднять этот вопрос. Если бы это было банковское приложение, обрабатывающее финансовые транзакции, вы могли бы найти другую работу, а не быть частью неэтичного решения.

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

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

• chmod 400 файл, чтобы другие пользователи не могли его прочитать
• добавить префикс точки ('.') К файлу, чтобы скрыть его от обычного списка каталогов
• переименуйте файл, чтобы сделать его менее интересным для чтения.
• будьте осторожны, чтобы не хранить ключ в простой строке - команда 'strings' напечатает все строки для печати из исполняемого образа Unix.

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

Answer 3

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

Вы можете prctl (2) с PR_SET_NAME, чтобы изменить имя процесса на лету. К сожалению, в настоящее время я не могу придумать какой-либо другой способ, кроме внедрения некоторого кода в запущенный процесс через ptrace (2), что означает, что вражеские процессы будут стремиться прочитать список процессов, прежде чем вы получите возможность изменить имя нового процесса: /

Кроме того, вы можете получить исправления ядра grsecurity и включить CONFIG_GRKERNSEC_PROC_USER:

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

Это остановит ps от возможности просмотра текущей команды, поскольку ps читает из /proc/<pid>/cmdline

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

Это плохая практика безопасности из-за проблем в архитектуре O / S. Ожидаете ли вы, что другие пользователи смогут перехватывать ваши системные вызовы? Я бы не стал обвинять разработчика, попавшего в эту ловушку.