История началась с того, что появилась необходимость написать "неубиваемый" процесс под Win32NT/2000/XP/2003 — на вроде поведения продукта Касперского 5 и 6 версии (в более ранних версиях такое поведение не замечено). Собсна процесс должен быть зашишён от TerminateProcess из любого доступного process explorer'а. (Прога есть основа IPC в проекте, а заодно ещё и инспектор выполнения и простенький маркер доступа). Вобщем варианты с двумя, кусками каждый из которых запускает другого при падении первого не канают — проблемы с синхронизацией, потеря буферных данных и прочее ... Перехватывать вызовы API функций также не хочеться, т.к. может быть расценено как попытка не санкционированного доступа и заблокировано. На сколько понимаю в антивирусе эта система построена за счёт качественного определения прав доступа (Process & Thread Security and Access Rights). Отталкиваясь от этого, решил написать код, который бы закрывал доступ к процессу и разрешал бы системе выгружать его, только в случае полной перезагрузки операционной системы. Базовые знание об этом процессе получил из MSDN и Windows System Programming Third Edition By Johnson M. Hart. Но как водиться — от теории до практики очень не лёгкий путь — и как следсвие возник сей вопрос.
Есть код:
...
//Initialize simple ACL wich will be used to setup process DACL
PACL lProcessDACL = NULL;
lProcessDACL = (PACL)LocalAlloc(LPTR, sizeof(ACL));
InitializeAcl(lProcessDACL, sizeof(ACL), ACL_REVISION);
//Creating well-known SID 'Everyone'
PSID lEveryoneSID = NULL;
SID_IDENTIFIER_AUTHORITY SIDAuthWorld = SECURITY_WORLD_SID_AUTHORITY;
SID_IDENTIFIER_AUTHORITY SIDAuthNT = SECURITY_NT_AUTHORITY;
AllocateAndInitializeSid(&SIDAuthWorld, 1, SECURITY_WORLD_RID, 0, 0, 0, 0, 0, 0, 0, &lEveryoneSID);
//Produce ACE wich explicity deny any operation for everyone
EXPLICIT_ACCESS lExplicitAcessForEveryone;
ACCESS_MASK lAllRights = PROCESS_ALL_ACCESS; //PROCESS_TERMINATE;
ZeroMemory(&lExplicitAcessForEveryone, sizeof(EXPLICIT_ACCESS));
lExplicitAcessForEveryone.grfAccessPermissions = lAllRights;
lExplicitAcessForEveryone.grfAccessMode = DENY_ACCESS;
lExplicitAcessForEveryone.grfInheritance= CONTAINER_INHERIT_ACE | OBJECT_INHERIT_ACE | SUB_CONTAINERS_AND_OBJECTS_INHERIT;
lExplicitAcessForEveryone.Trustee.TrusteeForm = TRUSTEE_IS_SID;
lExplicitAcessForEveryone.Trustee.TrusteeType = TRUSTEE_IS_WELL_KNOWN_GROUP;
lExplicitAcessForEveryone.Trustee.ptstrName = (LPTSTR)lEveryoneSID;
//Injecting produced ACE into prepared ACL
SetEntriesInAcl(1, &lExplicitAcessForEveryone, NULL, &lProcessDACL);
//Setting up current process DACL security information
SetSecurityInfo(GetCurrentProcess(), SE_KERNEL_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, lProcessDACL, NULL);
...
Этот самый код призван запретить любой доступ к информации процесса при любых условиях всем кому ни попади. Как вариант можно делать вместо/вместе с последним SetSecurityInfo(...) следующий вызов:
Соответсвенно данный код должен запрещать доступ к информации текущего потока.
Всё компилиться, обработку ошибок я убрал из привидённого кода дабы его не загромождать — но она присутсвует и на этапе выполнения логи показывают что все вызовы нормально отработали. Но после всего из соседнего процесса я могу подключиться к процессу выполневшему этот код, и даже вижу что в ACL его SD всего одна запись ... угадайте какая и при всём при этом я могу этот процесс хоть ногами пинать ... Сие поведение системы мне не понятно, и вот за разъяснениями к Вам и обращаюсь ... поможите кто чем может
Здравствуйте, MadCSilver, Вы писали:
MCS>и при всём при этом я могу этот процесс хоть ногами пинать ... Сие поведение системы мне не понятно, и вот за разъяснениями к Вам и обращаюсь ... поможите кто чем может
SeDebugPrivilege overrides the ACL on the process object.
соотв. эта привелегия включена в группе админов. если попытки снести процесс идут из под админов — тогда чему тут удивляться? кстати говоря, админы точно так же могут поправить DACL и дать себе доступ какой надо — просто им проще пользовать свою привелегию, кода меньше...
смысл же того что привелегия имеет преймущество над ACL — очень простой. Как было бы иначе возможно отлаживать, к примеру, системные процессы вроде сервисов крутящихся под SYSTEM?
... << RSDN@Home 1.2.0 alpha rev. 648>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Кстати анитивирус Касперского просто перехватывает ядерную NtOpenProcess, а перехватчик выглядит примерно так:
NTSTATUS NewNtOpenProcess (
OUT PHANDLE ProcessHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId OPTIONAL)
{
HANDLE ProcessId;
//Безопасным образом извлекаем ProcessId
if ((ULONG)ClientId > MmUserProbeAddress)//Проверяем что адресе ClientId находится ниже ядрерной памяти
return STATUS_INVALID_PARAMETER;
__try//Используем SEH, т.к. ClientId может указывать на непереданную память
{
ProcessId = ClientId->UniqueProcess;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
DPRINT("Exception");
return STATUS_INVALID_PARAMETER;
}
if ((ProtectedPid != 0)&&(ProcessId == ProtectedPid)) //защищаем процесс с указанным PID для нужного процесса
{
DPRINT("Access Denied!");
return STATUS_ACCESS_DENIED;
} else
return TrueNtOpenProcess(ProcessHandle, DesiredAccess,
ObjectAttributes, ClientId);
}
Вопросик в догонку ... я не спец в системе безопасности Windows, не подскажете может ли она эффективно приминяться для сетевого взаимодействия, и/или внутри системно для разграничивания достуапа к функциональности ... или лучше ваять своё своими руками? (мине как-то предпочтительней второй вариант — просто примеров эффективного использования WinSecurity как-то не попадалось ...)
Здравствуйте, Bill_Prisoner2, Вы писали:
B_P>Кстати анитивирус Касперского просто перехватывает ядерную NtOpenProcess, а перехватчик выглядит примерно так:
вне сомнения с перехватом жизнь прекраснее
возможно автору ветки интересны варианты с сокрытием процесса? кто не найдет — тот не убьет...
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, MadCSilver, Вы писали:
MCS>Вопросик в догонку ... я не спец в системе безопасности Windows, не подскажете может ли она эффективно приминяться для сетевого взаимодействия, и/или внутри системно для разграничивания достуапа к функциональности ... или лучше ваять своё своими руками?
задача не ясна, формулировки туманны. я бы запросил сразу больше инфы по постановке задачи, иначе сказать нечего кроме того что до сего времени вроде бы для сетевого взаимодействия в т.ч. применялась и подсистема безопасности окон, куда ж без нее
Про эффективность сложно вот так сказать — с чем сравниваем? В целом вроде не жалуются люди.
да и для внутренних задач — для ограничения доступа trustees к любым ресурсам — ОС тоже весьма широко применяют ACL и спец. аккаунты типа LOCAL SERVICE / NETWORK SERVICE, группы (Админов тех же) и их алиасы. Можно и своих правил наваять, рекомендую спец софт от МС для создания шаблонов security policy (такой MMC snap-in не помню имени) — на случай если возникнет идея все делать руками программно
MCS>(мине как-то предпочтительней второй вариант — просто примеров эффективного использования WinSecurity как-то не попадалось ...)
попробую ответить на этот вопрос в широком смысле (Узкого смысла все равно пока не видим), так сказать для всех "потенциальных клиентов" — пишущих под windows и сталкивающимся с безопасностью во всех ее проявлениях.
некие постулаты что ли:
1) если Вы видите что ресурсами можно рулить с помощью win security админу, то ничего не препятствует все то же делать программно
2) подумайте, есть ли в Вашей задаче роли которые эффективно можно сопоставить с аккаунтами в реальной ОС?
можно ли соотв спроектировать систему в терминах ресурсов, ролей и прав? большие шансы, если да — то Вы придете к возможности использования виндовой системе безопасности. А если нет — дизайн требует переработки скорее всего.
либо есть причины по которым действительно требуется что-то еще, но и в этом случае не факт, что этого уже не сделали в окнах (то есть надо писать самому с нуля) — просто менее известно.
Скорее всего все ресурсы, роли и права уже выражены в виде каких-то сущностей у вас в дизайне, но просто к ним не сопоставлены их виндовые аналоги — отчего и желание запрограммировать Windows по-своему.
Вот пример: как часто встречается идея вывешивать окно с вводом пароля в стандартном edit box с флажком hidden text и затем авторизацией пользователя по его слабенькому четырехзначному паролю "дупа" по базе с паролями в аксессе с использованием какого-то криптоалгоритма, скачанного из Сети 5 мин назад — и все это только затем чтобы в GUI знать чего показывать Васе (админу системы в терминах программы), а чего Пете (не админу в терминах программы). Все это можно возложить на ОС, но потребует чуть больше (а вообще скорее меньше ведь не надо ничего своего воротить! но почему то не все это сразу видят) усилий на написание true windows security кода — завести\сопоставить системные аккаунты Васи\Пети с чем-то (ролями) в GUI (он должен уметь их различать) и не спрашивать паролей (и тем более не хранить где-либо в каком-либо виде!!) вообще, ибо Вася и Петя должны авторизоваться в системе стандартным образом.
3) вариация 2) но уж больно хочется заострить: не плодите сущности без нужды. Всегда нужно подумать крепко, нужен ли еще один криптоалгоритм, когда в ОС встроено все что нужно через CryptoAPI, нужна ли своя схема аутентификации и авторизации, когда есть winlogon+GINA с Kerberos/SSPI и так далее вплоть до ажно своей системы безопасности целиком. Вы еще думаете что можете в разумный срок сделать что-то схожее по хар-м чем то что создавали лучшие люди в этой области?
Возможно стоит думать не о том как изобрести что-то свое, а как смочь использовать уже созданное светлыми головами, причем правильно (что очень часто как раз и не очень легко, ключевое слово правильно). Поэтому Ваш вопрос говорит что Вы в правильном направлении пошли, возможно не стоит сразу что-то свое делать, а сначала лучше осмотреться и подумать снова.
Успехов!
PS насчет "примеров не попадалось" есть вопрос — а Вы искали?
... << RSDN@Home 1.2.0 alpha rev. 648>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>Здравствуйте, MadCSilver, Вы писали:
MCS>>и при всём при этом я могу этот процесс хоть ногами пинать ... Сие поведение системы мне не понятно, и вот за разъяснениями к Вам и обращаюсь ... поможите кто чем может VAB>SeDebugPrivilege overrides the ACL on the process object.
VAB>соотв. эта привелегия включена в группе админов. если попытки снести процесс идут из под админов — тогда чему тут удивляться? кстати говоря, админы точно так же могут поправить DACL и дать себе доступ какой надо — просто им проще пользовать свою привелегию, кода меньше...
VAB>смысл же того что привелегия имеет преймущество над ACL — очень простой. Как было бы иначе возможно отлаживать, к примеру, системные процессы вроде сервисов крутящихся под SYSTEM?
А если заблокировать SeDebugPrivilege в маркере доступа? Это можно сделать?
и при всём при этом я могу этот процесс хоть ногами пинать ... Сие поведение системы мне не понятно, и вот за разъяснениями к Вам и обращаюсь ... поможите кто чем может 
