Как избежать конфликтов с другими программами, использующими общую память и семафор

Question

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

1. Как я могу гарантировать, что используемый мной семафор и shm не будут открыты другой программой, которая испортит их?Существует один способ запустить программу под отдельным пользователем со своей собственной группой пользователей и защитить общие объекты, ограничив их доступность только для этого пользователя и группы.Это ответ на мой вопрос, или есть какие-то подводные камни, может быть, на Windows?

2. Есть ли способ защитить их, если мне нужно запустить все программы под одним пользователем, или еслинекоторые программы запускаются с правами суперпользователя (ведь такие программы всегда есть)?

3. Я начал с установки «ключа» по умолчанию для shm и семафоров для всех случаев, когдахочу общаться вместе.Но может быть другая программа, которая уже взяла «ключ».Есть ли какая-то техника для решения такой проблемы?Я думал о выборе диапазона «ключей» (т. Е. Ключ будет целым числом в диапазоне 1000–2000), где, если программа не может получить ключ со значением по умолчанию, она пытается получить другой ключ из диапазона.

Я нашел связанный вопрос здесь , но он ничего не говорит о моих вопросах 2 и 3. Кроме этого вопроса, я не могу найти ничего, связанного с конфликтами и защитой семафоров и shmПохоже, это не принимается во внимание при написании программ.

Моя ситуация такова, что у меня есть программа, которая хочет взаимодействовать с другими экземплярами той же программы.Выполняется несколько «наборов» экземпляров одной и той же программы, где программы одного «набора» взаимодействуют вместе, а программы в другом «наборе» взаимодействуют вместе.Они общаются через защищенную семафором разделяемую память.Программа работает на различных платформах * nix и на Windows тоже.Они должны работать круглосуточно в течение нескольких лет и быть надежными и безопасными, вот почему я обеспокоен конфликтами.

Answer 1

Семафоры "защищают" разделяемую память, только если все программы, использующие ее, сотрудничают. То есть это позволяет программе, которая хочет играть хорошо, не портить общие объекты.

Это, однако, не гарантирует, что вредоносная программа сможет подключиться и повредить общие структуры, если захочет. Я не знаю каких-либо связанных с безопасностью функций в стандарте C ++, поэтому я бы посоветовал прибегнуть к средствам, специфичным для ОС.

Это означает, что вам может потребоваться разный код для Linux, Windows, Mac и т. Д. (В зависимости от того, какие у вас целевые платформы), может быть, даже другой код для разных версий ОС.

Answer 2

Если ваша основная проблема связана с конфликтами, как насчет использования GUID в качестве имени?Никто (в течение нашей жизни) никогда не придет с этим {897917A3-D44E-4f0d-A458-1318152CCCDA} случайно.

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

В Windows вы обычно используете структуры SECURITY_ATTRIBUTES при создании семафора и сопоставления файлов и mode_t (с creat / open / chmod / etc) в Unix.

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