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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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