а как вообще в общих чертах это делается под виндами начиная с висты?
а точнее могу ли я запустить произвольный процесс которому я хочу запретить использовать какието winapi или виртуализировать их вызовы перенаправив куда мне нужно?
я не очень в теме, но вроде в хп это просто было, а в висте и дальше? там же теперь нельяз ковыряться из драйвера в таблице системных вызовов или можно?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
B>а как вообще в общих чертах это делается под виндами начиная с висты? B>а точнее могу ли я запустить произвольный процесс которому я хочу запретить использовать какието winapi или виртуализировать их вызовы перенаправив куда мне нужно? B>я не очень в теме, но вроде в хп это просто было, а в висте и дальше? там же теперь нельяз ковыряться из драйвера в таблице системных вызовов или можно?
Вопрос большой, проще было бы ответить, зная конкретную задачу.
Платформы для перехвата произвольного API нет. На 64-х битных системах ядро следит за своей целостностью (Kernel Patch Protection (KPP) aka PatchGuard), поэтому перехватить без проблем произвольное нативное API тоже не получится. Предоставляемые MS'ом технологии можно, например, посмотреть тут
Показательные примеры Sandboxing'а (IMHO) в существующих решениях:
Виртуализация файловой системы решается файловым mini-фильтром, что показывает встроенный в Windows драйвер luafv.
Предоставляемое API для контроля реестра (CmRegisterCallbackEx) настолько не подходит для Sandboxing'а, что в отличие от файловой системы, MS дописала виртуализацию ключей реестра (для тоже задачи, что и luafv) просто куском кода ядра.
Насколько мне известно, сторонние решения применяют принцип: поставить перехват в user mod'е, а если перехват обошли, то на уровне драйвера блокировать обращения к не-завиртуализированным путям реестра.
Знаменитый Sandbox в Chromium, если я не ошибаюсь, полностью построен на перехватах уровня user mod'ных DLL. Соответственно, это Open Source продукт, детали используемых там принципов можно подсмотреть по сорцам.
по сути у меня задача близкая к хромиуму и прочим,
т.е. нужно запустить exe которому нет доверия так, чтобы он мог нанести никакого вреда случайно или специально,
кстати для этих целей имеет смысл запускать под учеткой с какимто особыми ограничениями прав? ну например чтобы он мог писать тока туда куда разрешат и не мог даже туда где стоит Everyone
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
B>т.е. нужно запустить exe которому нет доверия так, чтобы он мог нанести никакого вреда случайно или специально, B>кстати для этих целей имеет смысл запускать под учеткой с какимто особыми ограничениями прав? ну например чтобы он мог писать тока туда куда разрешат и не мог даже туда где стоит Everyone
The AppContainer environment is a restrictive process execution environment that can be used for legacy applications to provide resource security. An application running in an AppContainer can only access resources specifically granted to it.
Этот механизм используется в Edge и в UWP-приложениях из Windows Store, как часть встроенной песочницы. Механизм появился с 8-ки (для более старых систем есть, например, Restricted Tokens).
Сам я этот механизм не пробовал, но есть мысль, что запустить именно произвольный exe не получится: на какую-то опасную операцию он получит ERROR_ACCESS_DENIED и выйдет. Придется часть функций (набор функций заранее сказать сложно, но, например, Win32-hook'и вне своего процесса, RPC к системным процессам, типа SCM) банально перехватывать и эмулировать пустые ответы (или что-то вроде того).
Здравствуйте, Barbar1an, Вы писали:
B>Здравствуйте, EreTIk, Вы писали:
B>по сути у меня задача близкая к хромиуму и прочим, B>т.е. нужно запустить exe которому нет доверия так, чтобы он мог нанести никакого вреда случайно или специально, B>кстати для этих целей имеет смысл запускать под учеткой с какимто особыми ограничениями прав? ну например чтобы он мог писать тока туда куда разрешат и не мог даже туда где стоит Everyone
Очень хорошо EreTIk уже все расписал. Я лишь добавлю:
1. Даже на Windows XP можно использовать потоки, запущенные под Restricted-токенами и/или внутри Job-объектов с
соответствующими ограничениями. Restricted-субъект не имеет доступа ни к каким объектам, за исключением тех, к
которым ему доступ был выдан в явном виде (т.е. даже "Everyone" не поможет, нужно именно разрешающиее правило
для соответствующего SID-а). Дополнительно можно повырезать все "опасные" привилегии из токена.
2. В Windows Vista и выше для ограничений можно использовать Integrity Levels.
Например, Internet Explorer запускается на Low Integrity Level, песочницы Chrome/Acrobat и других
приложений — на Untrusted Integrity Level. Low/Untrusted-приложения не имеют доступа на запись в
объекты с более высоким IL, если только не присвоить тем нужный IL в явном виде.
3. Начиная с Windows 7 (если не изменяет память), есть дополнительный механизм защиты — Process Mitigation.
Например, можно запретить загружать неподписанные в Microsoft dll, работать с динамическим кодом
(VirtualAlloc/VirtualProtect/etc), запрещать системные вызовы GDI/Win32k, дочерние процессы и т.п.
См. функции SetProcessMitigationPolicy и UpdateProcThreadAttributes.
4. В Windows 8 и выше есть AppContainer — это встроенная "песочница", изолированная еще сильнее, чем
Integrity Levels. Запустить свое AppContainer-приложение не так уж сложно, хотя эта технология еще не совсем
документированная, но вот работать из AppContainer с объектами "как обычно" не выйдет, т.к. там целая
пачка самых разных ограничений. И снова, открывать из AppContainer-процесса можно лишь те объекты,
доступ к которым был выдан явно (либо для SID-а, соответствующего данному AppContainer-у, либо для
SID-ов "All Application Packages" или "All Restricted Application Packages" — Win10'1607).
5. Последнее слово в Sandboxing — это виртуализация (Virtualization-Based Security).
В Windows 10 эту тему подняли до такого уровня, что теперь, например, при включенном VBS даже из драйвера
нельзя вызывать некоторые инструкции (типа сброса WP или SMEP-битов в регистрах CR) или читать память
определенных приложений, несмотря на kernel mode и, казалось бы, абсолютный контроль над системой.
Но реализовать такой же гипервизор невероятно сложно...
Кстати, рекомендую к прочтению исходники Chromium Browser, там очень много по данной теме.
— вендор будет в курсе что его ехе будет отсендбоксен, поэтому сюрпризов ему ожидать не нужно
— нужны пайпы
— нужны дочерние процессы
— фс и всё остальное опасное — виртуализировано или изолировано
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>- вендор будет в курсе что его ехе будет отсендбоксен, поэтому сюрпризов ему ожидать не нужно
Привилегии какие у процесса ожидаются ?
B>- нужны дочерние процессы
дочерние процессы из комплекта EXE или сторонние тоже ?
LPC к системным службам ?
COM ?
B>- фс и всё остальное опасное — виртуализировано или изолировано
Опасными могут быть обычные сисколлы. Которые EXE вполне способен вызывать напрямую, а не через ntdll.
Эксплуатируем kernel bug и говорим "песочница, досвидания".
Кстати, устройства разрешаем открывать ?
Если нет — отвалится солидный пласт функционала ОС.
Если да — вот ещё один вектор атаки.
