Могу ли я создать мьютекс Windows глобально для тех процессов, которые знают пароль мьютекса?

Я хочу создать мьютекс Windows с помощью WinAPI, CreateMutex() а также OpenMutex(), Но из соображений безопасности я хочу, чтобы мьютекс был открыт теми процессами, которые знают «пароль» или магический код с жестким кодом. Я не хочу, чтобы мьютекс был доступен для всех процессов.

Например,
Создайте мьютекс с именем «Globel \ cd689f00-0462-11e5-b939-0800200c9a66».
Таким образом, только процесс, который знает имя мьютекса, может получить доступ к этому мьютексу. Но это не очень хорошее решение, потому что вы можете просто использовать Winobj.exe и у вас все еще есть шанс найти этот мьютекс.
Я хочу, чтобы этот мьютекс был защищен чем-то вроде ACL (Access Control Lists). Проблема в том, что я не могу найти способ создать свой собственный SID для ACL.

Вот что я знаю и чего хочу:
1. Я знаю, что могу сделать мьютекс доступным для многих процессов, назвав его «Global \ MyMutexName».
2. Я также пытаюсь понять ACL и SID, упомянутые в MSDN. Но я все еще не могу найти способ создать свой собственный SID (может быть, это не имеет смысла?).
3. Я не хочу повышать свои процессы до администратора.

3

Решение

То, что вы пытаетесь сделать, не является естественным для модели безопасности, которую использует Windows. Разрешения всегда предоставляются в зависимости от того, кто запускает исполняемый файл, а не от самого исполняемого файла. Однако, в зависимости от вашего сценария, могут быть подходящие варианты.

Если все вовлеченные процессы будут в контексте одного и того же пользователя, то вы можете использовать IPC (например, именованные каналы), чтобы идентифицировать ваши «дружественные» процессы и DuplicateHandle () передать дескриптор безымянному мьютексу между процессами.

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

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

Помните, что в любом из этих сценариев злоумышленник все еще может получить доступ к мьютексу — лучшее, что вы можете сделать, это сделать его немного сложнее. Например, если вы используете реальный мьютекс, злоумышленник может перечислить дескрипторы одного из процессов, идентифицировать мьютекс и продублировать дескриптор. (Или просто внедрить вредоносный код в один из якобы «дружественных» процессов, чтобы использовать дескриптор напрямую.) Даже IPC можно было бы шпионить и дублировать.

Вы должны серьезно подумать, стоит ли предельная выгода в плане безопасности значительного увеличения сложности. ИМО, это вряд ли будет.

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

5

Другие решения

Вы позволили бы Windows создать новый SID; не пытайтесь создать его самостоятельно. С этим SID вы можете затем создать ACL (Access Control List), который предоставляет доступ всем процессам, содержащим этот SID, и (неявно) отказывает всем остальным в этом праве. Этот ACL может быть применен к мьютексу, который защищает его.

Теперь, чтобы получить доступ, вам нужно создать жетон подражания для этого SID. Если я понимаю MSDN, процесс должен открыть ваш токен потока, установите TokenUser с помощью SetTokenInformationи затем примените модифицированный токен через SetThreadToken,

Этот токен олицетворения теперь используется при проверке ACL мьютекса.

MSDN не совсем ясно о процессе создания действительного SID пользователя; в процессе выше может потребоваться заменить «SID пользователя» на «SID группы».

3

По вопросам рекламы [email protected]