Привет.

Есть проблема алгоритмического характера, так сказать.
Представим себе фильтр реестра, будь то перехват SDT либо CmRegisterCallback() — не важно.
Допустим, мы имеем ключ реестра \Registry\Machine\TestKey, и в нём значение TestValue.
Таким образом полный путь к значению TestValue будет таким — \Registry\Machine\TestKey\TestValue.

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

Но вот попадается нам злонамеренная программка, которая решает обойти наш фильтр.
Поступает она просто: дёргает NtDeleteKey(), передавая ей \Registry\Machine\TestKey.
Ключ удалён, и наше драгоценное значение — тоже, что недопустимо.

Тоже самое касается и файлового фильтра — при удалении папки, удалятся содержащиеся в ней файлы, а файловый фильтр на это не отреагирует.
В голову приходит только одно решение и то кривое до ужаса — добавлять в список дополнительные правила, запрещающие удалять весь \Registry\Machine\TestKey, а также весь \Registry\Machine и конечно же весь \Registry, но это бред по-моему.

Подскажите, пожалуйста, люди добрые, что делать в данной ситуации?
Спасибо.

Здравствуйте,

А>Представим теперь, что у нашего фильтра есть правило — запрещать удаление данного ключа.
--
А почему нельзя организовать зашиту объекта стандартными средствами разграничения permissions для данного объекта?

С уважением,
Геннадий Майко.

Здравствуйте, Аноним, Вы писали:

А>Тоже самое касается и файлового фильтра — при удалении папки, удалятся содержащиеся в ней файлы, а файловый фильтр на это не отреагирует.

В этом вы ошибаетесь: запроса на удаление папки с файлами у файловой системы пока нет. Поэтому тому кто будет удалять папку придётся сначала послать запрос на удаление каждого файла.

Что же до вашего вопроса, то таки да, родительские ключи тоже надо защищать.

А>>Тоже самое касается и файлового фильтра — при удалении папки, удалятся содержащиеся в ней файлы, а файловый фильтр на это не отреагирует.
A>В этом вы ошибаетесь: запроса на удаление папки с файлами у файловой системы пока нет. Поэтому тому кто будет удалять папку придётся сначала послать запрос на удаление каждого файла.

Т.е. если послать IRP_MJ_SET_INFORMATON с классом FileDispositionInformation и с полем DeleteFile = TRUE, то папка не удалится?

A>Что же до вашего вопроса, то таки да, родительские ключи тоже надо защищать.

Так и думал.
Спасибо за ответ.

А>Но вот попадается нам злонамеренная программка, которая решает обойти наш фильтр.
А>Поступает она просто: дёргает NtDeleteKey(), передавая ей \Registry\Machine\TestKey.
А>Ключ удалён, и наше драгоценное значение — тоже, что недопустимо.
вестимо, нужно защищать родительский namespace тоже — в данном случае прямо с корня улья.

причем я Вам скажу больше, в контексте реестра Вам еще следует подумать о hive-related attacks и не забывать о других ControlSetXxx как минимум — иначе я поменяю Ваш ключ в др. месте и потом вынужу ОС загрузиться с его использованием через LKG (LastKnownGood) или вообще справлюсь средствами System Restore or/and other OS-supplied features. Например.

когда же разберетесь с этими очевидными атаками — можно будет обсудить и другие возможности для злонамеренных товарищей, если еще будет актуально.

А>Тоже самое касается и файлового фильтра — при удалении папки, удалятся содержащиеся в ней файлы, а файловый фильтр на это не отреагирует.
если не отреагирует фильтр — отреагирует FSD. Ибо папку удалить нельзя пока она непуста.

А>В голову приходит только одно решение и то кривое до ужаса — добавлять в список дополнительные правила, запрещающие удалять весь \Registry\Machine\TestKey, а также весь \Registry\Machine и конечно же весь \Registry, но это бред по-моему.
А>Подскажите, пожалуйста, люди добрые, что делать в данной ситуации?
можно использовать штатные ср-ва ОС — ACLs + наследование, как предложил Геннадий

Автор: Геннадий Майко
Дата: 15.01.08

— действительно, возможно все что Вам нужно сделать, это лишь сформировать и наклеить некий DACL на родителя. И перво-наперво ответить на вопрос — почему же никак нельзя использовать эти самые штатные ср-ва ОС? К сожалению, не так редко неиспользование правильных возможностей\сервисов ОС — признак ошибки в дизайне, а весь неслабый труд вокруг в итоге ничего не дает, кроме дыры в безопасности и тучи угробленного зря времени. Поэтому-то очень важно сразу хорошенько подумать, до любого кодирования. Как говорил мой тренер: "поспешай неторопясь"

И только если реально по-другому у Вас никак и надо обязательно что-то самопальное — тогда уже подменять\дополнять собой подсистему безопасности ОС единственное решение.

А уж то как Вы будете делать, это уже детали реализации — через набор правил или через какой-то универсальный алгоритм, который будет применяться при доступе к ресурсу на базе одного правила, с учетом всех ControlSetXxx, родительских ограничений-условий и т.п. Сделать же можно как угодно. Посему как разработчик Вы должны оценить все плюсы-минусы в контексте ТЗ (нам детали неизвестны — к примеру, произвольный ли ключ защищается или что-то конкретное? это может повлиять на выбор) и выбрать оптимальный вариант реализации.

А мы конечно можем помочь, если понадобится — так как дорожка-то хорошо тут уже натоптана.

PS Отчего аноним Может зарегистрируетесь уже? У нас рады новым коллегам.

A>>В этом вы ошибаетесь: запроса на удаление папки с файлами у файловой системы пока нет. Поэтому тому кто будет удалять папку придётся сначала послать запрос на удаление каждого файла.

А>Т.е. если послать IRP_MJ_SET_INFORMATON с классом FileDispositionInformation и с полем DeleteFile = TRUE, то папка не удалится?
удалится, если была пуста и ничего другого не мешает (DELETE permission has been granted, не корневая папка и т.п.)
если же не была пуста — думаю, будет отлуп со статусом STATUS_DIRECTORY_NOT_EMPTY.

ГМ>А почему нельзя организовать зашиту объекта стандартными средствами разграничения permissions для данного объекта?

По тем же причинам, по которым тот же касперчег в своей проактивной защите не стал так делать.

VAB>вестимо, нужно защищать родительский namespace тоже — в данном случае прямо с корня улья.

Да, я так и думал.

VAB>причем я Вам скажу больше, в контексте реестра Вам еще следует подумать о hive-related attacks и не забывать о других ControlSetXxx как минимум — иначе я поменяю Ваш ключ в др. месте и потом вынужу ОС загрузиться с его использованием через LKG (LastKnownGood) или вообще справлюсь средствами System Restore or/and other OS-supplied features. Например.

VAB>когда же разберетесь с этими очевидными атаками — можно будет обсудить и другие возможности для злонамеренных товарищей, если еще будет актуально.

Пока не актуально.
Но я обязательно задумаюсь об этом в будущем.
Ну а как доберусь до них, так сразу отпишусь здесь, уж это будьте уверены .

А>>Тоже самое касается и файлового фильтра — при удалении папки, удалятся содержащиеся в ней файлы, а файловый фильтр на это не отреагирует.
VAB>если не отреагирует фильтр — отреагирует FSD. Ибо папку удалить нельзя пока она непуста.

Что-то в этом роде я и ожидал. Спасибо.

VAB>А уж то как Вы будете делать, это уже детали реализации — через набор правил или через какой-то универсальный алгоритм

Через набор правил, ибо защищаемые объекты заранее не известны.
Собственно реализация правил уже готова.
Теперь достаточно будет просто добавить новый тип правил, что-то вроде value-related rules , которые будут защищать родительские ключи.

VAB>А мы конечно можем помочь, если понадобится — так как дорожка-то хорошо тут уже натоптана.

Вот за это респект!
Я тоже помогаю другим по мере сил.

VAB>PS Может зарегистрируетесь ...?

А я уже. Вы только посмотрите внимательнее, логи сервера, например. Вы ж модератор.
Только тсс! Это секрет.

VAB>>PS Может зарегистрируетесь ...?
А>А я уже. Вы только посмотрите внимательнее, логи сервера, например. Вы ж модератор.
не всегда есть время и если честно желание пинкертонить — не проще ли уважать приватность собеседника?
да и Янус не показывает инфу — в отличие от админской веб-морды, тут Вы правы.

А>Только тсс! Это секрет.
да, догадки не подводят — причем не только касательно этого форума, как выяснилось по случаю Однако, какой богатый послужной список. Но, тсс! (с) ...хоть и непонятна причина по которой был выбран анонимный аккаунт — ведь нормальный вопрос для обсуждения, кого тут стесняться — все ж свои...

Здравствуйте, Аноним, Вы писали:

А>Но вот попадается нам злонамеренная программка, которая решает обойти наш фильтр.
А>Поступает она просто: дёргает NtDeleteKey(), передавая ей \Registry\Machine\TestKey.
А>Ключ удалён, и наше драгоценное значение — тоже, что недопустимо.

Вопрос почему нельзя штатными средствами?

А>Подскажите, пожалуйста, люди добрые, что делать в данной ситуации?

Сделайте и штатными средствами и по своему. Вам ведь надо как можно больше трудностей создать, как я понимаю, ну так вот и накрутите... Штатные средства справляются с вашей задачей.

Вообще-то NtDeleteKey не удаляет ключ если у него есть подключи. Так же как с директориями — надо обходить рекурсивно.

А>Вообще-то NtDeleteKey не удаляет ключ если у него есть подключи.

А если подключей нет, но есть значения?

А>А если подключей нет, но есть значения?
тогда удаляет. Но тем не менее защищать от удаления надо тока один ключ, а не всех его парентов

А>тогда удаляет. Но тем не менее защищать от удаления надо тока один ключ, а не всех его парентов

Да, действительно. Спасибо.