Является ли секретный токен, сгенерированный с / dev / urandom, хорошим способом защиты демона?

Question

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

Я хочу реализовать это следующим образом:

• Во время запуска демон генерирует случайный 128-байтовый секретный токен, читая / dev / urandom. / dev / random не годится, потому что он может заблокировать читателя на произвольное время.
• Демон прослушивает сокет домена Unix.
• Демон помещает секретный токен и имя файла сокета в переменные окружения. Каждый подпроцесс, который он порождает, может подключиться к демону, используя имя файла и секретный токен.
• Демон отклоняет соединение, если секретный токен не верен.

Вопросы:

• Я знаю, что / dev / random имеет более высокую энтропию, чем / dev / urandom. Но достаточно ли / dev / urandom? Если нет, что я должен использовать?
• Достаточно ли велик размер токена?
• Должен ли я заблокировать память, в которой хранится токен? Я не думаю, что это необходимо, поскольку демон генерирует новый токен при каждом запуске, поэтому к тому времени, когда злоумышленнику удастся украсть жесткий диск и извлечь токен из файла подкачки, он уже будет бесполезен.
• Должен ли я обнулять память, в которой токен хранится во время выключения?
• Что-нибудь еще, что я должен сделать?

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

Answer 1

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

Другой подход - запросить у ОС учетные данные (pid, uid, gid) из сокета Unix. В Linux вы должны использовать getsockopt(sock, SOL_SOCKET, SO_PEERCRED, &cr, &cr_len) (man 7 socket). Солярис имеет getpeerucred. К сожалению, это не переносимо, но многие системы имеют аналогичные возможности для сокетов Unix. Хотя это сложно, D-Bus содержит код , который делает это на ряде различных систем .

Answer 2

Что ж, если вы собираетесь поместить токен в переменную окружения, тогда любой, кто имеет такие же или более высокие привилегии (т. Е. UID), что и эти процессы, сможет читать, тогда используйте токен! Это своего рода делает отдых вопрос спорный вопрос !? Если вас беспокоит безопасность между процессами в одном блоке (вы говорили о локальном IPC), то не используйте переменную окружения для хранения токена - это легко проверить (EV).

Answer 3

Да, безопасность, обеспечиваемая / dev / urandom, достаточно хороша. Многие программы используют его для случайности (для SSL, аутентификации и т. Д.). Практически единственное время / dev / random - хорошая идея, когда генерируется какой-то токен, который должен быть защищен в течение многих лет, например закрытый ключ для сертификата.

Кто-то упомянул возможность просматривать память процесса, если у вас одинаковый UID. Вы можете избежать этого, заставив ядро ​​думать, что это setuid-процесс, то есть, если главный процесс запускается как root, вы можете выполнить fork, exec и setuid () для непривилегированного пользователя. Другие процессы с таким же UID не смогут просматривать память этого процесса.

Подход поиска учетных данных также работает с именованными сокетами UNIX, а не только с парами сокетов.

Answer 4

Если вы разветвляетесь (но не исполняете), достаточно просто хранить их в локальной памяти. Если вы также используете exec (), вам, вероятно, (как вы указали в своем комментарии к Jim) необходимо передать токен (и путь к сокету домена) по каналу.

Если вы используете это на серверах без головы, / dev / random МОЖЕТ быть немного голодным, поэтому использование / dev / urandom будет (вероятно) лучшим вариантом, если у вас нет подходящего источника шума для подачи / dev / random с.