Запустите.exe как очень ограниченный пользователь
Я пытаюсь запустить program.exe в очень ограниченном режиме (Windows). Это означает, что program.exe должен иметь доступ к пяти TXT-файлам и не иметь никаких других разрешений, таких как запуск нового процесса, завершение работы, редактирование других файлов и т. Д.
Я потратил месяц на то, чтобы добиться этого, но результатов до сих пор нет. Я пытался запустить его как пользователь с ограниченными правами: runas /trustlevel:10000 "program.exe"
, а затем добавил разрешения:icacls program.exe /grant *S-1-5-12:F
Но, кажется, у такого пользователя все еще есть некоторые права, для инсталяции он может запустить notepad.exe и explorer.exe, и это неприемлемо в моем случае. Также я играл с функцией winapi CreateProcessAsUser(), но это привело к тому же результату. Поэтому мой вопрос: как я могу запустить program.exe с этими ограничениями, может быть, мне следует создать нового пользователя с ограничениями? Как?
PS: в основном я хочу получить примитивную песочницу.
Спасибо.
Итак, благодаря вашей помощи я написал этот код:
hToken = NULL;
OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &hToken);
SID_AND_ATTRIBUTES sidsToDisable;
ConvertStringSidToSid(L"S-1-1-0", &sidsToDisable.Sid);
sidsToDisable.Attributes = NULL;
SID_AND_ATTRIBUTES sidsToRestrict;
ConvertStringSidToSid(L"S-1-1-0", &sidsToRestrict.Sid);
sidsToRestrict.Attributes = NULL;
CreateRestrictedToken(hToken,NULL,1,&sidsToDisable,0,NULL,1,&sidsToRestrict,&hToken);
PROCESS_INFORMATION pi;
if (CreateProcessAsUser(hToken, wszPath, NULL, NULL, NULL,TRUE, CREATE_NEW_CONSOLE /*| CREATE_SUSPENDED*/, NULL, NULL, &si, &pi))
{
//...
//ok process created
}
Но это не работает. Ошибки 0xc0000022 возникают постоянно или 0xc00000142 при использовании SID администратора. Когда я создаю hToken SaferComputeTokenFromLevel(), он работает нормально. Что я делаю неправильно?
1 ответ
Считается, что тщательная песочница невозможна. Смотрите также связанный PDF.
Если это должно быть надежно, единственным вариантом является полноценная виртуальная машина. Конечно, если изолированное приложение должно быть исполняемым файлом Windows, это имеет последствия для лицензирования.
Если он не должен быть настолько надежным, то в принципе должно быть возможно собрать что-то, что может быть достаточно. Для этого вам потребуются права администратора, но системная служба может запустить изолированное приложение от имени непривилегированного пользователя.
Сложной частью, я думаю, будет создание подходящего токена. Я думаю, что в идеале вам нужен токен с уникальным идентификатором сеанса входа в систему, но больше ничего.
Использование LSA API, вероятно, является наилучшим подходом, поскольку позволяет синтезировать произвольный токен, но он сложен и не очень хорошо документирован.
Вы можете поэкспериментировать с дублированием и / или модификацией токена, полученного из ImpersonateAnonymousToken, но я не уверен, будет ли возможно включить уникальный SID сеанса входа в систему.
Объединение LogonUser (с учетной записью пользователя, созданной для этой цели) с CreateRestrictedToken должно быть простым и адекватным. Это, вероятно, место для начала.
Вы также должны убедиться, что уровень целостности токена достаточно низкий. Я бы предположил, что либо S-1-16-0
или же S-1-16-1
это самый низкий возможный уровень.
Вы захотите создать новую оконную станцию для изолированного процесса. Вот почему нам нужен SID входа в систему, чтобы мы могли предоставить разрешения токена оконной станции. В противном случае процесс не сможет запуститься.
Если процесс генерирует графический интерфейс, вам придется каким-то образом его удалать. В идеале вы должны изменить сам процесс так, чтобы часть GUI была отдельной и не нуждалась в песочнице. В противном случае в принципе должна быть возможность скопировать растровое изображение с изолированного рабочего стола и перенаправить на него щелчки мыши и нажатия клавиш. Я не уверен, насколько надежным это будет.
Чтобы запретить изолированному процессу запуск дочерних процессов, поместите его в объект задания. Вы можете установить ограничение активного процесса для задания равным 1, чтобы предотвратить создание дочерних процессов. (Это не является действительно необходимым IMO, так как дочерние процессы будут иметь те же ограничения, что и родительские процессы, но это можно сделать.)
Ваш последний комментарий предполагает, что, возможно, вам не нужен даже этот уровень надежности. Если это так, вы можете избавить себя от проблем удаленного доступа к GUI, запустив процесс на своем рабочем столе и оконной станции пользователя.
Вам все равно потребуется сгенерировать подходящий токен, но вам может не потребоваться использовать отдельную учетную запись пользователя и сеанс входа в систему; если это так, CreateRestrictedToken должно быть достаточно. В качестве источника вы можете использовать собственный токен интерактивного пользователя.
Вам все равно нужно будет понизить уровень целостности токена, чтобы защитить его от разрушительных атак.
Вы все еще можете использовать объект задания, чтобы предотвратить запуск дочерних процессов.
JOBOBJECT_BASIC_UI_RESTRICTIONS может использоваться для обеспечения некоторого уровня защиты от атак на пользовательский интерфейс.
В этом случае вам может даже не потребоваться доступ администратора. Я не уверен, случайно.
Этот подход недостаточно надежен для запуска потенциально вредоносных исполняемых файлов, но если песочница предназначена только для предосторожности при резервном копировании, она может быть адекватной.