Доброго времени суток, уважаемые.
Случился у нас с г-ном Andrew.W Worobow скромный спор о проблемах сабжа...
Суть "конфликта" — я по незнанию считаю, что для того чтобы удовлетворять условиям некоторого ТЗ
Здравствуйте, Ligen, Вы писали:
L>Доброго времени суток, уважаемые. L>Случился у нас с г-ном Andrew.W Worobow скромный спор о проблемах сабжа... L>Суть "конфликта" — я по незнанию считаю, что для того чтобы удовлетворять условиям некоторого ТЗ
Для того, чтобы удовлетворить условиям вашего ТЗ, достаточно перехватить операцию открытия исполняемого файла. Т.е. предлагается контролировать процедуру открытия файлов на исполнение (FILE_EXECUTE). Соответственно, корректно это решается с помощью (мини)фильтра файловой системы. Можно, конечно, и ZwCreateFile перехватить, но этот вариант обладает уязвимостью (если делать в лоб).
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>Для того, чтобы удовлетворить условиям вашего ТЗ, достаточно перехватить операцию открытия исполняемого файла. Т.е. предлагается контролировать процедуру открытия файлов на исполнение (FILE_EXECUTE). Соответственно, корректно это решается с помощью (мини)фильтра файловой системы. Можно, конечно, и ZwCreateFile перехватить, но этот вариант обладает уязвимостью (если делать в лоб).
IMHO для реализации ТЗ вообще не нужно ничего перехватывать, нужно лишь расставить правильно права доступа на каталоги и наследование прав файлами. Т.е достаточно просто некой админской тулзы, чтобы сделать этот процесс удобнее.
Здравствуйте, TarasCo, Вы писали:
TC>IMHO для реализации ТЗ вообще не нужно ничего перехватывать, нужно лишь расставить правильно права доступа на каталоги и наследование прав файлами. Т.е достаточно просто некой админской тулзы, чтобы сделать этот процесс удобнее.
Этот подход будет работать только для тех файлов, доступ к которым на запуск уже разграничен. Условно говоря, можно прийти с дискетой/флешкой и запустить программу с нее.
Административно проблему можно решить только в XP и выше путем настройки политики ограниченного использования программ (software restriction policies).
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>Здравствуйте, TarasCo, Вы писали:
TC>>IMHO для реализации ТЗ вообще не нужно ничего перехватывать, нужно лишь расставить правильно права доступа на каталоги и наследование прав файлами. Т.е достаточно просто некой админской тулзы, чтобы сделать этот процесс удобнее.
Совершщенно согласен... Этого инструменнта более чем достаточно. Есть там свои сложности, но как таковой этот механизм, полностью достаточен.
SS>Административно проблему можно решить только в XP и выше путем настройки политики ограниченного использования программ (software restriction policies).
Однако Вы не правы, МС ещё в далеком уже и не помню каком году, предлагал спец. тулузу... Которая кстати, построена на схожей с изначальной идее...
Здравствуйте, Andrew.W Worobow, Вы писали:
TC>>>IMHO для реализации ТЗ вообще не нужно ничего перехватывать, нужно лишь расставить правильно права доступа на каталоги и наследование прав файлами. Т.е достаточно просто некой админской тулзы, чтобы сделать этот процесс удобнее.
AWW>Совершщенно согласен... Этого инструменнта более чем достаточно. Есть там свои сложности, но как таковой этот механизм, полностью достаточен.
Пожалуйста, приведите пример административного вмешательства, в результате которого пользователь не сможет запустить программу с отчуждаемого носителя.
SS>>Административно проблему можно решить только в XP и выше путем настройки политики ограниченного использования программ (software restriction policies).
AWW>Однако Вы не правы, МС ещё в далеком уже и не помню каком году, предлагал спец. тулузу... Которая кстати, построена на схожей с изначальной идее...
AWW><a target='_blank' class='m' href='http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q320181'>Q320181</a>...
AWW>Ну если не поленитесь прочитать, смешная тулуза...
Сами-то читали?
To restrict access to a program, the program must reside on the Terminal server.
Здравствуйте, Sergey Storozhevykh, Вы писали:
AWW>>Совершщенно согласен... Этого инструменнта более чем достаточно. Есть там свои сложности, но как таковой этот механизм, полностью достаточен.
SS>Пожалуйста, приведите пример административного вмешательства, в результате которого пользователь не сможет запустить программу с отчуждаемого носителя.
Это как это? У себя что-ли на компе мышкой потыкать, или что?... Сказано, всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу... И вообще всё эти перехвадчики, это от незнания... как тоже можно сделать, законными средствами... И от незнания, того что этого перехвата не достаточно...
SS>Сами-то читали?
Читал, и что, а вы пробовали... Я то вот ещё в 2000, году всё это читал...
...
SS>Теперь перечитайте ТЗ от автора. Не поленитесь
Интересно, причем тут "ТЗ", ... Вы сказали, что "Административно проблему можно решить только в XP и выше"... Вы ну вот вам и ответ от МСа...
А по ТЗ, ну бред, всё это... И детский сад... Пусть он перехватит "то", что он хочет, а я запушу "то", что я захочу... причем без административных прав...
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Это как это? У себя что-ли на компе мышкой потыкать, или что?... Сказано, всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу... И вообще всё эти перехвадчики, это от незнания... как тоже можно сделать, законными средствами... И от незнания, того что этого перехвата не достаточно...
То есть вы утверждаете, что встроенного механизма разграничения доступа к файлам "более чем достаточно"
, для того чтобы реализовать замкнутость программной среды. Попробую доказать вам обратное.
Как известно, полноценный (применительно к нашему случаю — способный контролировать доступ к файлу на исполнение) механизм контроля доступа к файловым объектам реализуется средствами файловой системы NTFS и позволяет настроить политику доступа к файлам и папкам в пределах одного логического тома. Следовательно, для того чтобы привести систему в безопасное состояние, необходимо на каждом NTFS-томе отдельно реализовать выбранную модель контроля доступа. Очевидно, что таким образом настроенная система будет сохранять свойства защищенности только в условиях отсутствия возможности подключения к системе новых томов. Т.к. мы не можем установить правила разграничения доступа априори для вновь появляющихся томов.
Другими словами, встроенный механизм разграничения доступа к файлам, охарактеризованный вами как полностью достаточный для обеспечения замкнутости программной среды, будет корректно реализовывать свои защитные функции (т.е. обеспечивать защиту от несанкционированного запуска исполняемых файлов) только в системах, где отсутствует возможность подключения отчуждаемых носителей (CD, дискета, флешка).
Не согласны? Аргументируйте.
Для того чтобы обеспечить замкнутость программной среды в общем случае, механизм контроля доступа должен быть реализован поверх всех файловых систем. С помощью файлового фильтра, например.
SS>>Сами-то читали?
AWW>Читал, и что, а вы пробовали... Я то вот ещё в 2000, году всё это читал...
Для тех, кто в танке, повторяю:
To restrict access to a program, the program must reside on the Terminal server.
Или вы считаете, что защищаться от несанкционированного запуска программ целесообразно только на терминальном сервере? Обоснуйте.
SS>>Теперь перечитайте ТЗ от автора. Не поленитесь
AWW>Интересно, причем тут "ТЗ", ... Вы сказали, что "Административно проблему можно решить только в XP и выше"... Вы ну вот вам и ответ от МСа...
Автор ищет решение проблемы для Win2000.
AWW>А по ТЗ, ну бред, всё это... И детский сад... Пусть он перехватит "то", что он хочет, а я запушу "то", что я захочу... причем без административных прав...
Голословно как-то. Расскажите, как вы обойдете механизм обеспечения замкнутости программной среды, выполненный на основе файлового (мини)фильтра, контролирующего операцию открытия файла на исполнение?
Съемные носители это вечная головная боль для администраторов Windows . Вот если бы томы не монтировались автоматически, а на подобие UNIX требовали команды mount, а для исполнения команды нужны были бы административные привилегии, вот бы было всем счастье .
Кстати, юзер может еще примонтировать сетевой диск, для этого не нужны особые привилегии. Из этого следует, что подобные меры безопасности придется делать на всех машинах сети, иначе юзеры начнут "помогать" друг другу.
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>То есть вы утверждаете, что встроенного механизма разграничения доступа к файлам "более чем достаточно"
, для того чтобы реализовать замкнутость программной среды. Попробую доказать вам обратное.
Нет, не надо передёргивать, это _вы_ сказали, "встроенного механизма разграничения доступа к файлам", я сказал только... и могу повторить — "всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу"
Для тех, кто видит разграничение прав доступа, только на NTFS, разжую — Вся система виндов построена на обьектах, у обьекта, если вы конечно знаете, а не только умеете хуки ставить, есть SECURITY_DESCRIPTOR, внутрии которого есть и Owner, Group, Sacl, Dacl...
И причем тут всего лищь, какая то частная NTFS, я не знаю?... Видимо вы сами видите только её, и с этим вашим виденением спорите...
И ещё — IoCreateDeviceSecure, функция не експортируется кернелом, а реализуется через "wdmsec.lib", и не использует IoCreateDevice, а на прямую работает с обьектами.... То есть делает тоже, что и IoCreateDevice, но только SECURITY_DESCRIPTOR берёт не через IopCreateDefaultDeviceSecurityDescriptor, а из переданных её параметров ...
Да, в библиотеке эта фанкция называется WdmlibIoCreateDeviceSecure.
...
SS>Как известно, полноценный ....
Вы так много написали, и всё простите не о чём...
SS>Не согласны? Аргументируйте.
С чем я должен быть не соглаен? С вашим видением ядра WINDOWS?
Могу только постараться обьяснить, в чем ваш подход ошибочен в приципе —
Что, по сути предлагается (вы предлагаете): добавить некий дополнительный признак для файла, "можно запускать/нельзя". И
назначить некие ваши внутрении ACLы типа : "администратору можно" а "другим нет"...
Но зачем? Когда запуск файла начинается с его открытия и причем от имени того кто его запускает. Зачем городить ещё один самопальный атрибут, когда есть и так полный набор, и причем регулируемый для каждого конкретного пользователя, а не тупо АДМИН/ЮЗЕР. Могу только предположить, что всё это скорее всего просто от незнания "как правильно сделать", а сделать надо.
Ну согласитесь, что вместо того чтобы просто расставить права доступа не разумно пихать код (и кстати ведь наверняка с уязвимостями) в ядро.
*******************************************************************
По тому, что ниже спорить :)) Больше не буду... Ибо не о чем.
*******************************************************************
SS>
SS>To restrict access to a program, the program must reside on the Terminal server.
SS>Или вы считаете, что защищаться от несанкционированного запуска программ целесообразно только на терминальном сервере? Обоснуйте.
No comment
AWW>А по ТЗ, ну бред, всё это... И детский сад... Пусть он перехватит "то", что он хочет, а я запушу "то", что я захочу... причем без административных прав...
SS>Голословно как-то. Расскажите, как вы обойдете механизм обеспечения замкнутости программной среды, выполненный на основе файлового (мини)фильтра, контролирующего операцию открытия файла на исполнение?
Знаете, я уже начинаю сомневаться в вашей, простите адекватности... ЧТО голословно? Причем тут какой-то файловый мини-фильтр... Это вы в вашей голове за меня нафантазировали... Я нигде, такого не говорил... Про "ТО" читайте тут
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Нет, не надо передёргивать, это _вы_ сказали, "встроенного механизма разграничения доступа к файлам", я сказал только... и могу повторить — "всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу"
AWW> Для тех, кто видит разграничение прав доступа, только на NTFS, разжую — Вся система виндов построена на обьектах, у обьекта, если вы конечно знаете, а не только умеете хуки ставить, есть SECURITY_DESCRIPTOR, внутрии которого есть и Owner, Group, Sacl, Dacl...
AWW>И причем тут всего лищь, какая то частная NTFS, я не знаю?... Видимо вы сами видите только её, и с этим вашим виденением спорите...
Пожалуйста, объясните мне: для каких типов объектов, кроме файловых, нужно установить атрибуты доступа, чтобы контролировать процедуру запуска процесса? Я просто не в курсе, потому и написал про NTFS.
AWW>Добавлю —
AWW>читайте до прояснение — IoCreateDeviceSecure...
А, понял! Точно, надо установить запрет исполнения устройства. Блин, только вот не пойму какого. Подскажите, а?
SS>>Не согласны? Аргументируйте.
AWW>С чем я должен быть не соглаен? С вашим видением ядра WINDOWS?
Я утверждаю, что:
Встроенный механизм разграничения доступа к файлам будет корректно реализовывать свои защитные функции (т.е. обеспечивать защиту от несанкционированного запуска исполняемых файлов) только в системах, где отсутствует возможность подключения отчуждаемых носителей (CD, дискета, флешка).
AWW>Могу только постараться обьяснить, в чем ваш подход ошибочен в приципе —
AWW>Что, по сути предлагается (вы предлагаете): добавить некий дополнительный признак для файла, "можно запускать/нельзя". И AWW> назначить некие ваши внутрении ACLы типа : "администратору можно" а "другим нет"...
Так, хотя можно и полномасштабную модель дискреционного контроля доступа развернуть. Можно мандатную, не суть.
AWW>Но зачем? Когда запуск файла начинается с его открытия и причем от имени того кто его запускает. Зачем городить ещё один самопальный атрибут, когда есть и так полный набор, и причем регулируемый для каждого конкретного пользователя, а не тупо АДМИН/ЮЗЕР. Могу только предположить, что всё это скорее всего просто от незнания "как правильно сделать", а сделать надо.
Да, можно разграничить для уже присутствующих в системе файловых объектов, но не для вновь появляющихся в следствие монтирования новых томов. Основная проблема состоит в том, что вы не можете назначить атрибуты доступа тем объектам, которые еще не присутствуют в системе. В пределах одного тома это еще разруливается наследованием, но в рамкай всей системы — никак. Это следствие фундаментального принципа, положенного в основу всей разграничительной политики доступа: права устанавливаются для объекта, но не субъекта доступа.
AWW>Ну согласитесь, что вместо того чтобы просто расставить права доступа не разумно пихать код (и кстати ведь наверняка с уязвимостями) в ядро.
Если бы все было, как вы говорите, зачем MS ввела в Windows XP политику ограниченного использования программ, о которой я уже писал выше? Они, наверное, забыли у вас спросить, как реализовать замкнутость программной среды уже существующими на тот момент средствами?
Кстати, MS "впихнула" код, реализующий process restriction policy, в kernel32.dll — на уровне CreateProcess.
AWW>Знаете, я уже начинаю сомневаться в вашей, простите адекватности... ЧТО голословно? Причем тут какой-то файловый мини-фильтр... Это вы в вашей голове за меня нафантазировали... Я нигде, такого не говорил... Про "ТО" читайте тут
Простите, вы про что? Я никаким, простите боком не отпираюсь ибо нет повода... Вы опять похоже хотите выдать желаемое за действительное, процитируете мои слова, где, я говорил, что-то про "файлы"? Я опять, уже похоже третий раз повторяю — "всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу".
Странный, вы всё-таки какой-то, зачем мне приписывать то чего я не говорил, и даже могу сказать больше... Мне это даже во сне не могло приснится! Файлы. Это вы все время с файлами боретесь, вместо того чтобы, один раз и до конца разобраться с моделью безопасности WINDOWS.
SS>Пожалуйста, объясните мне: для каких типов объектов, кроме файловых, нужно установить атрибуты доступа, чтобы контролировать процедуру запуска процесса? Я просто не в курсе, потому и написал про NTFS.
Я вообще ничего не понял, вы простите на грубом слове несёте какой то детский лепет — Что такое "контролировать процедуру запуска процесса" Вы простите про что? Я вот уже почти 15 лет как занимаюсь системным программированием и не знал, что есть какая-то ОСОБАЯ процедура (Наверное в ядре ) которая "запускает" процессы.
SS>А, понял! Точно, надо установить запрет исполнения устройства. Блин, только вот не пойму какого. Подскажите, а?
Хотите можете явно указать "запрет", но я думаю что и просто "не разрешить чтение" будет вполне достаточно. А что касается "какого" конкретно устройства, ну итдипенс...
SS>Я утверждаю, что:
SS>
SS>Встроенный механизм разграничения доступа к файлам будет корректно реализовывать свои защитные функции (т.е. обеспечивать защиту от несанкционированного запуска исполняемых файлов) только в системах, где отсутствует возможность подключения отчуждаемых носителей (CD, дискета, флешка).
Ну могу только повторить — в windows, всё построено на объектах, объекты это ВСЁ и файлы и потоки и секции... Да всё, за редким-редким исключением... И как такового нет "Встроенный механизм разграничения доступа к файлам" есть к объектам...
Вы вообще в какой области специализируетесь? Что никогда не слышали про WinObj?
Там в верху у неё есть такая кнопочка "properties", посмотрите... Авось вопросов будет поменьше.
Да и почитайте у Руссиновича — главу "Подсистема ввода-вывода" там в общих чертах все хорошо рассказано...
SS>Да, можно разграничить для уже присутствующих в системе файловых объектов, но не для вновь появляющихся в следствие монтирования новых томов.
Опять какой-то детский сад — да легко! Ну ура, и не раз уже делалось...
SS>Основная проблема состоит в том, что вы не можете назначить атрибуты доступа тем объектам, которые еще не присутствуют в системе.
Да откуда же такая уверенность, что "не можете"... Вы что-нибудь про наследование слышали... Все тома монтируются на каких-то устройствах, так просто "ТОМОВ" не бывает...
SS>Если бы все было, как вы говорите, зачем MS ввела в Windows XP политику ограниченного использования программ, о которой я уже писал выше? Они, наверное, забыли у вас спросить, как реализовать замкнутость программной среды уже существующими на тот момент средствами?
Не знаю, это бизнес... Захотели сделали, а почему 1000 и одна причина может быть для этого...
А вообще, это что аргумент в пользу невозможности? Странный однако...
PS:
Да кстати, процесс можно и вообще без исполняемого файла создать... Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
> процесс можно создать прямо из памяти > И для этого даже админских прав не надо
если можно, с этого места поподробнее.
или в двух словах, саму идею.
в смысле, не как процесс из памяти создать,
а как без админских прав, как вообще без исполняемого файла.
Только на РСДН помимо ответа на вопрос, можно получить еще список орфографических ошибок и узнать что-то новое из грамматики английского языка (c) http://www.rsdn.ru/forum/cpp/4720035.1.aspx
AWW> :))) Да кстати, процесс можно и вообще без исполняемого файла создать... :))) Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
Особенно интересует "без админских прав". Идея? Как?
[skip]
AWW>PS:
AWW> Да кстати, процесс можно и вообще без исполняемого файла создать... Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
Опять двадцать пять А как-же "фундамент".
Пусто
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
Я читаю эту ветку, как детектив. Жду каждого нового поста. Не хочу судить кто прав, кто нет, просто получаю удовольствие от чтения. Парни — не останавливайтесь! Все это уже однозначно идет в мемориз .
Здравствуйте, TarasCo, Вы писали:
TC>Я читаю эту ветку, как детектив. Жду каждого нового поста. Не хочу судить кто прав, кто нет, просто получаю удовольствие от чтения. Парни — не останавливайтесь! Все это уже однозначно идет в мемориз .
Не у меня уже дежавю начинается от чтения
Пусто
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
Здравствуйте, Andrew.W Worobow, Вы писали:
SS>>Пожалуйста, объясните мне: для каких типов объектов, кроме файловых, нужно установить атрибуты доступа, чтобы контролировать процедуру запуска процесса? Я просто не в курсе, потому и написал про NTFS.
AWW>Я вообще ничего не понял, вы простите на грубом слове несёте какой то детский лепет — Что такое "контролировать процедуру запуска процесса" Вы простите про что? Я вот уже почти 15 лет как занимаюсь системным программированием и не знал, что есть какая-то ОСОБАЯ процедура (Наверное в ядре ) которая "запускает" процессы.
Демагогия. Сергей задал конкретный вопрос, а вы ему гнете пальцы про 15 лет
SS>>А, понял! Точно, надо установить запрет исполнения устройства. Блин, только вот не пойму какого. Подскажите, а?
AWW>Хотите можете явно указать "запрет", но я думаю что и просто "не разрешить чтение" будет вполне достаточно. А что касается "какого" конкретно устройства, ну итдипенс...
опять конкретный вопрос, и уклончивый ответ — ит депендс.
SS>>Я утверждаю, что:
SS>>Встроенный механизм разграничения доступа к файлам будет корректно реализовывать свои защитные функции (т.е. обеспечивать защиту от несанкционированного запуска исполняемых файлов) только в системах, где отсутствует возможность подключения отчуждаемых носителей (CD, дискета, флешка).
AWW>Ну могу только повторить — в windows, всё построено на объектах, объекты это ВСЁ и файлы и потоки и секции... Да всё, за редким-редким исключением... И как такового нет "Встроенный механизм разграничения доступа к файлам" есть к объектам...
про объекты все мы прекрасно знаем. Но разговор идет про отчуждаемые носители, а не про то, что поток или мутекс есть объект. Опять демагогия.
AWW>Вы вообще в какой области специализируетесь? Что никогда не слышали про WinObj? Там в верху у неё есть такая кнопочка "properties", посмотрите... Авось вопросов будет поменьше. AWW>Да и почитайте у Руссиновича — главу "Подсистема ввода-вывода" там в общих чертах все хорошо рассказано...
А тут уже просто наезд. Развести демагогию, не дать ни одного конкретного ответа, а затем наехать на оппонента — это наглость уже.
убедительная просьба следить за объемом цитирования — модератор
AWW> Да кстати, процесс можно и вообще без исполняемого файла создать... Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
чудеса да и только Создайте, а мы всем форумом внимательно понаблюдаем. Или опять сказано не подумав ?
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Простите, вы про что? Я никаким, простите боком не отпираюсь ибо нет повода... Вы опять похоже хотите выдать желаемое за действительное, процитируете мои слова, где, я говорил, что-то про "файлы"? Я опять, уже похоже третий раз повторяю — "всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу".
Хорошо, если вы настаиваете, поставим вопрос шире: возможно ли использовать модель безопасности Windows для организации замкнутости программной среды в общем случае?
AWW>Странный, вы всё-таки какой-то, зачем мне приписывать то чего я не говорил, и даже могу сказать больше... Мне это даже во сне не могло приснится! Файлы. Это вы все время с файлами боретесь, вместо того чтобы, один раз и до конца разобраться с моделью безопасности WINDOWS.
Вот давайте вместе и разберемся.
SS>>Пожалуйста, объясните мне: для каких типов объектов, кроме файловых, нужно установить атрибуты доступа, чтобы контролировать процедуру запуска процесса? Я просто не в курсе, потому и написал про NTFS.
AWW>Я вообще ничего не понял, вы простите на грубом слове несёте какой то детский лепет — Что такое "контролировать процедуру запуска процесса" Вы простите про что? Я вот уже почти 15 лет как занимаюсь системным программированием и не знал, что есть какая-то ОСОБАЯ процедура (Наверное в ядре ) которая "запускает" процессы.
Вместо того, чтоб ответить на вопрос по существу вы прицепились к слову. Несерьезно.
Мы ведь не обсуждаем вопросы процедурного программирования, но находимся в русле технической дискуссии о более общих проблемах, как-то: обсуждение механизмов защиты и способов их применения для организации замкнутости программной среды. Теперь поясню какое значение я вкладываю в термин "процедура" в предложенном контексте. Процедура — последовательность действий, необходимых к исполению для достижения какого-либо результата. Так понятно? Ну собственно, можно заглянуть в любой толковый словарь.
SS>>А, понял! Точно, надо установить запрет исполнения устройства. Блин, только вот не пойму какого. Подскажите, а?
AWW>Хотите можете явно указать "запрет", но я думаю что и просто "не разрешить чтение" будет вполне достаточно.
Для того чтобы запретить/разрешить исполнение, вполне достаточно манипуляций с атрибутом EXECUTE. Это, если хотите, необходимое и достаточное условие.
AWW>А что касается "какого" конкретно устройства, ну итдипенс...
Для какого конкретно устройства нужно настроить соответствующие атрибуты доступа, в случае необходимости блокировать запуск процессов со съемного USB-диска? Не торопитесь отвечать на этот вопрос, ниже я покажу, что это в принципе невозможно.
AWW>Ну могу только повторить — в windows, всё построено на объектах, объекты это ВСЁ и файлы и потоки и секции... Да всё, за редким-редким исключением... И как такового нет "Встроенный механизм разграничения доступа к файлам" есть к объектам...
Тут надо понимать, что есть пространство имен диспетчера обектов (device objetcs, driver objects, sections etc.), и дополнительные пространства имен: файловой системы, реестра, еще чего-нибудь. Так вот безопасностью рулит тот, кто пространство имен организует. В случае файлов — файловая система, в случае реестра — диспетчер конфигурации и т.п. Таким образом, при открытии файла диспетчер объектов не участвует в определении разрешенных прав доступа к объекту. Поэтому я сознательно опускаю в рассуждениях механизм разграничения доступа, реализованный в недрах диспетчера объектов. Расставьте любые атрибуты доступа на устройство, предствляющее том файловой системы, или физическое устройство диска, ассоциированное с устройством тома через VPB, — эти атрибуты будут просто игнорироваться при открытии файла на томе.
Поэтому установка атрибутов на объекты устройств не может повлиять на процедуру запуска процессов. Теперь понятно, почему я все время аппелирую к файлам?
AWW>Вы вообще в какой области специализируетесь? Что никогда не слышали про WinObj?
Кстати, я пользуюсь WinObjEx, она удобней — рекомендую.
SS>>Да, можно разграничить для уже присутствующих в системе файловых объектов, но не для вновь появляющихся в следствие монтирования новых томов.
AWW>Опять какой-то детский сад — да легко! Ну ура, и не раз уже делалось...
Не верю. Можно вас попросить описать метод настройки "бесопасности", как вы выражаетесь, с тем, чтобы на впоследствии примонтированном USB-диске доступ к файлам был соответствующим образом разграничен. Для полноты ощущений представим, что файловая система на USB-диске FAT32.
SS>>Основная проблема состоит в том, что вы не можете назначить атрибуты доступа тем объектам, которые еще не присутствуют в системе.
AWW>Да откуда же такая уверенность, что "не можете"... Вы что-нибудь про наследование слышали... Все тома монтируются на каких-то устройствах, так просто "ТОМОВ" не бывает...
Наконец-то мы добрались до корня ваших заблуждений. С точки зрения системы безопасности диспетчера объектов — том, это объект, для которого разграничивается доступ. Диспетчер объектов не делает никаких предположений о содержимом тома и, тем более, атрибутах доступа к сущностям, расположенным на томе. Все, что внутри тома, отдается на откуп файловой системе, которая этот том монтирует.
SS>>Если бы все было, как вы говорите, зачем MS ввела в Windows XP политику ограниченного использования программ, о которой я уже писал выше? Они, наверное, забыли у вас спросить, как реализовать замкнутость программной среды уже существующими на тот момент средствами?
AWW>Не знаю, это бизнес... Захотели сделали, а почему 1000 и одна причина может быть для этого...
AWW>А вообще, это что аргумент в пользу невозможности? Странный однако...
Какой-никакой, а аргумент. Хочется все-таки дождаться аргументов и вашей стороны.
AWW>PS:
AWW> Да кстати, процесс можно и вообще без исполняемого файла создать... Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
Это как, заклинаниями? Опустим технические нюансы, которые, насколько я знаю, вам просто не позволят это сделать. Даже если представить, что вы умеете это делать, точнее вы написали эксплоит, который умеет плодить такие процессы, то в условиях корректно настроенной замкнутости программной среду, вы просто не сможете запустить свой эксплоит.
И, если вы все-таки будете продолжать упорствовать в своем намерении запустить такой фейковый процесс, то значит и ваша хваленая "безопаснось", на которую вы, судя по всему молитесь, не всемогуща?
SS>Хорошо, если вы настаиваете, поставим вопрос шире: возможно ли использовать модель безопасности Windows для организации замкнутости программной среды в общем случае?
Уточняю: политика ограниченного использования программ, появившаяся Windows XP, в расчет не принимается, исходя из условий оригинальной задачи. Ищем решение для всех NT-based OS
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW> Да кстати, процесс можно и вообще без исполняемого файла создать... Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
С нетерпением жду развития темы. И про процесс из пустого места и вообще про безопасность...
Здравствуйте, IID, Вы писали:
IID>Демагогия. Сергей задал конкретный вопрос, а вы ему гнете пальцы про 15 лет
Знаете. я думаю, что тибетские шаманы оценят конференцию нейро-хирургов вообще как сборише шарлотанов...
AWW>> Да кстати, процесс можно и вообще без исполняемого файла создать...
IID>чудеса да и только Создайте, а мы всем форумом внимательно понаблюдаем. Или опять сказано не подумав ?
Чудак-человек это наверное для вас чудеса... Конечно если вам и под досом больше 600Кб не удавалось получить то вполне может быть...
"Не допускается проявление грубого или неуважительного отношения к другим участникам форума. Оскорблять и обзывать собеседника, ставить под сомнение его профессиональную квалификацию, придираться к его нику, указывать на орфографические и синтаксические ошибки и т. д. запрещается."
Предлагаю не ставить под сомнение профессионализм ув. AWW, дабы не нарушить правила, а просто обратиться к ув. модераторам с нижайшей просьбой забанить участника за нарушение правил форума. IMHO Андрей вместо того, чтобы серьезно участвовать в конференции просто прикалывается и намерено провоцирует участников на нарушения правил.
Здравствуйте, Andrew.W Worobow, Вы писали:
SS>>Пожалуйста, объясните мне: для каких типов объектов, кроме файловых, нужно установить атрибуты доступа, чтобы контролировать процедуру запуска процесса? Я просто не в курсе, потому и написал про NTFS.
AWW>Я вообще ничего не понял, вы простите на грубом слове несёте какой то детский лепет — Что такое "контролировать процедуру запуска процесса" Вы простите про что?
SS>>Да, можно разграничить для уже присутствующих в системе файловых объектов, но не для вновь появляющихся в следствие монтирования новых томов.
AWW>Опять какой-то детский сад — да легко! Ну ура, и не раз уже делалось...
убедительная просьба или разъяснять свою позицию до уровня детского сада (т.е. с примерами для детсадовцев и ссылками) или прекратить нарушать пункт правил выше — модератор
... << RSDN@Home 1.2.0 alpha rev. 655>>
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.
Здравствуйте, Andrew.W Worobow, Вы писали:
IID>>Демагогия. Сергей задал конкретный вопрос, а вы ему гнете пальцы про 15 лет AWW> Знаете. я думаю, что тибетские шаманы оценят конференцию нейро-хирургов вообще как сборише шарлотанов... AWW> Да кстати, процесс можно и вообще без исполняемого файла создать... Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
Андрей мне кажется я понимаю куда ты клонишь — но по-моему уже пора перестать трактовать про шаманов и провоцировать форум, а написать что именно имелось ввиду и какие там ограничения (а они есть).
IID>>чудеса да и только Создайте, а мы всем форумом внимательно понаблюдаем. Или опять сказано не подумав ? AWW> Чудак-человек это наверное для вас чудеса... Конечно если вам и под досом больше 600Кб не удавалось получить то вполне может быть...
по всем формальным признакам стоит выписать небольшой бан в профилактических целях, но мне не хочется лишать одну из сторон права защитить свою позицию. Посему предлагаю либо прекратить флуд про детсад и шаманов либо обсудить "имеющееся уже много лет решение" нормально — без эмоций и взаимных подколок. В противном случае дискуссия будет порезана и большей частью уедет в мусор как не имеющая смысла — модератор
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.
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>Для того, чтобы удовлетворить условиям вашего ТЗ, достаточно перехватить операцию открытия исполняемого файла. Т.е. предлагается контролировать процедуру открытия файлов на исполнение (FILE_EXECUTE). Соответственно, корректно это решается с помощью (мини)фильтра файловой системы. Можно, конечно, и ZwCreateFile перехватить, но этот вариант обладает уязвимостью (если делать в лоб).
насколько я помню, перехват в классическом (НТ4+) фильтре IRP_MJ_CREATE с целью контролировать FILE_EXECUTE приведет к следующей проблеме: невозможно отличить когда файл, скажем executable PE Image, имеющий право быть запущенным в т.ч. — просто открывается для чтения\MMF доступа или когда его реально хотят открыть с целью запуска
лучше уж сразу смотреть за созданием process' backed section и соотв. наводить контроль в этом месте — ZwCreateSection
... << RSDN@Home 1.2.0 alpha rev. 655>>
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>лучше уж сразу смотреть за созданием process' backed section и соотв. наводить контроль в этом месте — ZwCreateSection
каким образом "смотреть" ? пропатчив SDT ? тогда будут проблемы с поддержкой x64 платформ,
может быть в варианте с фильтром файловой системы можно использовать какую-то эвристику для определения того, что это именно CreateProcess
Здравствуйте, Ivan, Вы писали:
VAB>>лучше уж сразу смотреть за созданием process' backed section и соотв. наводить контроль в этом месте — ZwCreateSection I>каким образом "смотреть" ? пропатчив SDT ? тогда будут проблемы с поддержкой x64 платформ,
про 64 бита в ветке не было требования пока, хотя согласен — там делается иными способами
I>может быть в варианте с фильтром файловой системы можно использовать какую-то эвристику для определения того, что это именно CreateProcess
может быть. Согласен, вариантов решения может быть много, просто предложенный выше один из самых быстрых в реализации + собственно замечание было вызвано оригинальным текстом Сергея про решение на отлов FILE_EXECUTE в момент открытия и не более.
... << RSDN@Home 1.2.0 alpha rev. 655>>
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.
Здравствуйте, IID, Вы писали:
VAB>>лучше уж сразу смотреть за созданием process' backed section и соотв. наводить контроль в этом месте — ZwCreateSection
IID>а еще проще смотреть за ZwResumeThread, хоть это и хуки, которые вы нам несоветовали
по разным причинам может быть не проще. Кстати ZwCreateSection — естественно тоже хуки, кототорых я по-прежнему не советую
если есть официальные пути решения, т.е. без серьезной на то причины. А причина вроде невозможности отловить нечто необходимое другим (легальным) способом, согласитесь, может тянуть на серьезную, не так ли?
именно об этом случае и говорится — см. когда хуки оправданны — пункт 3.
... << RSDN@Home 1.2.0 alpha rev. 655>>
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.
VAB>А причина вроде невозможности отловить нечто необходимое другим (легальным) способом, согласитесь, может тянуть на серьезную, не так ли?
Валера, на самом деле есть совершенно легальный путь, причем начиная с 2000'ых... Вот только народ постоянно путает security и safety... А разница между ними как между замком с контролькой и навороченным банковским... А по сути, все эти "блокировки запуска" не более чем защита от дурака...
Вот если уж кому надо, но только имейте ввиду, это не безопасность!
создайте в разделе \\Registry\\MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\AppCertDlls
ключ с именем AppSecDll типа REG_EXPAND_SZ, куда положите, что-то типа %SystemRoot%\system32\<ваша>.dll... На самом деле их там может быть много, имейте это ввиду.
В этой вашей dll'ке должна быть точка входа CreateProcessNotify ...
либо APPCERT_IMAGE_OK_TO_RUN = 1
либо APPCERT_CREATION_ALLOWED = 2 или APPCERT_CREATION_DENIED = 3
при вызове с APPCERT_IMAGE_OK_TO_RUN, вас как бы спрашивают "этот имедж ОК или нет"
Если вас программа устаривает то верните STATUS_SUCCESS, не устаривает верните STATUS_UNSUCCESSFUL...
при вызове с APPCERT_CREATION_ALLOWED или APPCERT_CREATION_DENIED, вас уведомляют об результатах голосования...
То есть — если APPCERT_CREATION_ALLOWED то процесс с этим именем будет образован, ну и если APPCERT_CREATION_DENIED то соответсвенно нет.
Даже если вы вернули APPCERT_IMAGE_OK_TO_RUN, а другая после вас загруженая такая же dll на этот образ вернет APPCERT_CREATION_DENIED, то будет действовать последний резьюм. Ну и наоборот.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>насколько я помню, перехват в классическом (НТ4+) фильтре IRP_MJ_CREATE с целью контролировать FILE_EXECUTE приведет к следующей проблеме: невозможно отличить когда файл, скажем executable PE Image, имеющий право быть запущенным в т.ч. — просто открывается для чтения\MMF доступа или когда его реально хотят открыть с целью запуска
Скорее всего вы имеете в виду проблему с LoadLibraryEx(LOAD_LIBRARY_AS_DATAFILE). Это API некорректно устанавливает атрибут исполнения в DesiredAccess при открытии файла, вследствие чего возможны ложные срабатывания. Это заметно напрягает, например, когда Explorer при отображении содержимого каталога запрашивает иконки из ресурсов бинарников.
А так, корректно написанная программа должна указывать FILE_EXECUTE только если она действительно хочет исполнить файл, FILE_READ — когда читать.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>создайте в разделе \\Registry\\MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\AppCertDlls
AWW>ключ с именем AppSecDll типа REG_EXPAND_SZ, куда положите, что-то типа %SystemRoot%\system32\<ваша>.dll... На самом деле их там может быть много, имейте это ввиду.
AWW>В этой вашей dll'ке должна быть точка входа CreateProcessNotify ...
Интересно. Пожалуй, это самый простой сбособ получить требуюмую функциональность. По крайне мере, проще, чем писать файловый фильтр . Но, как и в случае фильтра, требуется разрабатывать свой модуль, реализующий защитный механизм. Так что полностью встроенными средствами, по-видимому, никак?
AWW>NTSTATUS CreateProcessNotify ( LPCWSTR lpApplicationName, ULONG Reason );
Ну остается только добавить, что соглашение о вызовах — STDCALL.
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>Интересно. Пожалуй....
Я вас поздравляю... Вы в числе не многих в мире, кто теперь знает об этой возможности...
AWW>>NTSTATUS CreateProcessNotify ( LPCWSTR lpApplicationName, ULONG Reason );
SS>Ну остается только добавить, что соглашение о вызовах — STDCALL.
Е-с-т-е-с-т-в-е-н-н-о! И никак иначе.
Да... В конце, я там не очень понятно написал про голосование. Но иными словами — один голос против перевешивает все. Если кто-то проголосовал, против, то процесс образован не будет.
SS> Так что полностью встроенными средствами, по-видимому, никак?
Уважаемый SS, к сожалению я достаточно занятой человек. Появится время и я постараюсь популярно обьяснить как что и где...
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Уважаемый SS, к сожалению я достаточно занятой человек. Появится время и я постараюсь популярно обьяснить как что и где...
Уважаемый коллега, к счастью, мне не горит, и я с удовольствием подожду...
Хотелось бы спросить где можно о таких вещах почитать более конкретно ?
особенно о > \\Registry\\MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\AppCertDlls
таких ветках и их содержимом и прилагающемся к ним длл ках ?
Здравствуйте, Romikgy, Вы писали:
R>Хотелось бы спросить где можно о таких вещах почитать более конкретно ? R>особенно о >> \\Registry\\MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\AppCertDlls R>таких ветках и их содержимом и прилагающемся к ним длл ках ?
Вот здесь и читай. Можешь считать это первоисточником... Да скорее всего это так и есть...
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>Скорее всего вы имеете в виду проблему с LoadLibraryEx(LOAD_LIBRARY_AS_DATAFILE). Это API некорректно устанавливает атрибут исполнения в DesiredAccess при открытии файла, вследствие чего возможны ложные срабатывания. Это заметно напрягает, например, когда Explorer при отображении содержимого каталога запрашивает иконки из ресурсов бинарников.
нет, я не имел ввиду именно этот случай.
SS>А так, корректно написанная программа должна указывать FILE_EXECUTE только если она действительно хочет исполнить файл, FILE_READ — когда читать.
Корректно написанные программы — разве можно на это полагаться? Особенно там где специально пытаются обойти "хороших парней", полагающихся на "корректные программы". Если любая программа длиннее 100 строк уже потенциально некорректна — в плане багов (периодически встречаются статейки в т.ч. с мат обоснованием по этому поводу и, как правило, с апелляциями к статистике реальных проектов. выводы по качеству в среднем в индустрии стары как мир — оно ужасно, раз программы из 100 строк уже формально некорректны )
PS не знаю куда это лучше вставить и в ответ на чью фразу, посему оставлю тут: на самом деле если рассматривать проблему максимально широко — уметь контролировать запуск любого user-mode кода, запущенного честно через CreateProcess, процессы конструируемые на базе секций (на памяти) умельцами, свои лоадеры, скрипты, 16-bit код и т.п. то запросто может оказаться что даже файловый фильтр или решение Андрея (пока его не пощупал руками сложно сказать для чего оно годится, если даже работает — тотальное отсутствие инфы в гугле настораживает, хотя указанный ключ реестра в kernel32.dll присутствут и это факт. Который был получен через 30 сек после прочтения интереснейшей информации от Андрея
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>решение Андрея (пока его не пощупал руками сложно сказать для чего оно годится, если даже работает — тотальное отсутствие инфы в гугле настораживает, хотя указанный ключ реестра в kernel32.dll присутствут и это факт. Который был получен через 30 сек после прочтения интереснейшей информации от Андрея
AWW>Валер, да работает это работает... А в гугле нет, потому, что "ещё" нет... Теперь будет. Я здесь первый раз про это рассказал... Вот и всё...
Андрей, проверил. Супер! все как заявлено в спецификации, вот теперь можно трешку влепить неглядя
AWW>Этот способ, совершенно не безопасен !!!1 ... Обходится так же как и всё... см. описание к вот этому про NtCreateThread...
это понятно. Да ты уже сам сказал про security & safety. согласен сразу был с этим утверждением. потому и был написан PS
Однако сам способ чувствую, окажется нов не только для меня — и это несомненно ценная информация не только для шареваршиков
PS накидал тут тестовое приложение, блокирующее запуск notepad'a. Исходники проекта + сопутствующие артефакты доступны тут (этот же проект годится для тестирования Windows Logon Notification Packages, WLNP) — кто хочет убедиться что все работает — "налетай торопись, покупай живопись"
краткая инструкция: кладем wlnp.dll в %systemroot%\system32. Если хотим тестить WLNP — пускаем wlnp.reg, если хотим тестить блокировку приложений, регистрируемся через AppCertDlls.reg. Reboot. Достаем DbgView/WinDbg и смотрим логи. Для проверки пытаемся дернуть notepad.exe — навскидку решил блокировать все что имеет слово notepad в пути. Смотрим на экран и в лог.
Вот кусочек реального лога:
CreateProcessNotify: C:\Program Files\Far\Far.exe Reason: 1
CreateProcessNotify: C:\Program Files\Far\Far.exe Reason: 2
//...Far was launched fine. Notepad is being launched....
CreateProcessNotify: C:\WINDOWS\system32\notepad.EXE Reason: 1
CreateProcessNotify: C:\WINDOWS\system32\notepad.EXE Reason: 3
//...and blocked with a fun message (which is RtlNtStatusToDosError(STATUS_UNSUCCESSFUL), I suppose)
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.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Этот способ, совершенно не безопасен !!!1 ... Обходится так же как и всё... см. описание к вот этому про NtCreateThread...
если создавать процесс/поток через native api, они не пройдут регистрацию в csrss, а это необходимо для нормальной работы win32 api
но обойти проверки в самом CreateProcess, конечно, можно — например, пропатчив код kernel32.dll в памяти — и это, кстати, отличает данный метод от других. если проверки выполняются не на клиентской стороне, а в ядре например — пользователь не сможет их обойти не имея административных прав.
убедительная просьба следить за объемом цитирования — модератор
AWW>Вот здесь и читай. Можешь считать это первоисточником... Да скорее всего это так и есть...
но это не полный список всех возможностей, хотелось бы больше инфы
Здравствуйте, Ivan, Вы писали:
I>Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>>Этот способ, совершенно не безопасен !!!1 ... Обходится так же как и всё... см. описание к вот этому про NtCreateThread... I>если создавать процесс/поток через native api, они не пройдут регистрацию в csrss, а это необходимо для нормальной работы win32 api
I>но обойти проверки в самом CreateProcess, конечно, можно — например, пропатчив код kernel32.dll в памяти — и это, кстати, отличает данный метод от других. если проверки выполняются не на клиентской стороне, а в ядре например — пользователь не сможет их обойти не имея административных прав.
Модель безопасности, положенная в основу безопасности windows не имеет в своей концепции такого механизма как блокировка запуска приложений, это попросту там не нужно. И даже более того, на мой взгляд, в какой-то степени вредно, так как с одной стороны создаёт дополнительную излишнюю нагрузку на систему, а с другой формирует вредную иллюзию того, что это усиливает безопасность системы в целом.
В основу модели безопасности виндоуз, заложен принцип разграничения доступа к объектам системы, который ограничивает действия пользователей вне зависимости от того как эти "действия" оформлены. Не важно как именно называется программа которая пытается получить доступ к файлу. Не важно даже, что "это" — двоичный код или скрипт из текстового файла.
Встроенный механизм который я опубликовал, предназначен исключительно для обеспечения safety... По аналогии с формой штырьков вилки у бытовой техники предназначенной для использования в Японии, Америки или России... Конечно, пользователь может вилку переделать, но после того как техника сгорит ему останется винить только себя...
Мне лично все эти попытки создания "ограниченной программной среды" смешны... И напоминают затею писать против ветра...
Можно нагородить сложнейшие системы, которые будут блокировать 98% процентов способов исполнить некий код в системе... Но это простите не безопасность, это детский сад, так как если в саму архитектуру системы не заложен такой механизм, не проводилось анализа на полноту, то оставшиеся 2% сразу становятся 100% дырой... И ни о какой безопасность уже и речи быть не может...
Собирался на вашем примере популярно рассказать, что "блокировка запуска приложений", это пустая и глупая идея... Но, к сожалению, достаточно свободного времени не предвидится ...
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>>>А, понял! Точно, надо установить запрет исполнения устройства. Блин, только вот не пойму какого. Подскажите, а?
... SS>Для какого конкретно устройства нужно настроить соответствующие атрибуты доступа, в случае необходимости блокировать запуск процессов со съемного USB-диска? Не торопитесь отвечать на этот вопрос, ниже я покажу, что это в принципе невозможно.
Вспоминать и проверять, что конкретно надо по USB времени нет да и честно говоря не охота, но думаю, что и примера с сидюком, вам будет достаточно —
Предположим в вашей системе есть два устройства IDE один жёсткий диск и сд-ром...
Воспользуемся WinObjEx, если вам так больше нравиться —
находим в "\Device\Ide"
\Device\Ide\IdeDevicePOT1L0-c — CD-ROM Drive
\Device\Ide\IdeDevicePOT1L0-4 — Disk Drive
Устанавливаем для устройства \Device\Ide\IdeDevicePOT1L0-c "Deny" "execute", для пользователя «aaa».
запускаем "Commаnd Prompt"
c:\> dir d:
конечно если у вас cd-rom это "D:"
видим содержимое диска, то есть для администратора запрета нет — все работает.
В запускаем RunAs /user:aaa /noprofile cmd.exe
с:\>dir d:\
Access is denied.
Ок. Что и требовалось...
///////////////////////////////////////////////////////////////////
SS>Для того чтобы запретить/разрешить исполнение, вполне достаточно манипуляций с атрибутом EXECUTE. Это, если хотите, необходимое и достаточное условие.
Нет вполне достаточно будет, и "не разрешения чтения"
SS>Поэтому установка атрибутов на объекты устройств не может повлиять на процедуру запуска процессов. Теперь понятно, почему я все время аппелирую к файлам?
см. выше. И на будущее, я советую вам не быть столь самоуверенным, не убедившись в собственной правоте. А то можно, что называется ....
SS>И, если вы все-таки будете продолжать упорствовать в своем намерении запустить такой фейковый процесс, то значит и ваша хваленая "безопаснось", на которую вы, судя по всему молитесь, не всемогуща?
А при чем тут, безопасность. Если я скажем, так воспользуюсь, какой либо "не документированной" возможностью разрешённой на выполнение программы, и сумею внедрить в неё код, который откроет файл, прочитает его, и в мозгах создаст процесс, из нужной мне программы, для которой вы запретили только выполнение, то это будет, то что называется брызги...
[skip]
AWW>Вот здесь и читай. Можешь считать это первоисточником... Да скорее всего это так и есть...
Отвлеченно... кто-то утянул, достал то что кто-то потерял. Но мало кто это досконально читал
Пусто
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Встроенный механизм который я опубликовал, предназначен исключительно для обеспечения safety...
Требование и проверка цифровой подписи драйвера в висте это security или safety? Реализовано это требование таким образом, что даже имея административные права нельзя загрузить неподписанный драйвер. Думаю, дело здесь в том, что даже если речь идет о safety, а не security — инициатором запуска приложения или попытки загрузить неподписанный драйвер может быть не пользователь, а некоторое приложение. в этом случае наличие "дыр" сводит всю safety на нет. можно вспомнить еще DEP — это тоже механизм скорее для безопасности пользователя, но возможность отключить dep программно для процесса привела к тому, что вирусам не составляет труда его обойти.
Здравствуйте, Ivan, Вы писали:
AWW>>Встроенный механизм который я опубликовал, предназначен исключительно для обеспечения safety...
I>Требование и проверка цифровой подписи драйвера в висте это security или safety?
И то и другое... Так как режим ядра подразумевает возможности суперпользователя, а ошибки в драйверах привести к краху системы...
Я предложил это деление security и safety, и специально делаю акценты на их различии, только для того, чтобы люди недавно пришедшие в безопасность, ясно чувствовали разницу... Но это ни как не противоположнисти это в некотором роде паралельные вещи. В безопасности есть ещё и такие сушности ( простите за научность — сам терпеть не могу все эти заумные высказывания) как живучесть, целосность, надёжность... и пр. Все они подразумевают ограничение свободы действий пользователя... И в системе могут быть предусмотрены специальные механизмы для обеспечения и облегчения их реализаций, но использовать их, для целей и задач security нельзя.
I>Реализовано это требование таким образом, что даже имея административные права нельзя загрузить неподписанный драйвер. Думаю, дело здесь в том, что даже если речь идет о safety, а не security — инициатором запуска приложения или попытки загрузить неподписанный драйвер может быть не пользователь, а некоторое приложение. в этом случае наличие "дыр" сводит всю safety на нет.
Задачи safety, скроминые — по сути обычный фул пруф... И преодоление её не страшно, а ценность не высока... Поэтому и цена разработки ( а следовательно и качество кода) должна быть адекватной... А ошибки не критичными. Поэтому и её ставят, туда где она стоит. Ну вы поняли.
I> можно вспомнить еще DEP — это тоже механизм скорее для безопасности пользователя, но возможность отключить dep программно для процесса привела к тому, что вирусам не составляет труда его обойти.
Зашита от вирусов, это ещё одна, другая задача, помимо safety и security...
Мне вообще странно, почему так получилось, что у нас всё называется безопасность, а отсюда на мой взгляд вся эта путаница, с целями, задачами и механизмами. На мой взгляд, правильнее было-бы использовать термины безопасность, для safety. Охрана для securuty. Мне кажется, что виной всему товарищ Берия||Сталин — "Министерство Государственной Безопасности"...
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>TO шареваршики: Спешите проги писать... Это самое "оно" то что называется — KNOW-HOW....
AWW>Этот способ, совершенно не безопасен !!!1 ... Обходится так же как и всё... см. описание к вот этому про NtCreateThread...
спасибо, интересный способ
но я бы не стал на него полагаться — вся проверка в контексте вызовающего процесса
если бы в контексте какого-нибудь csrss более органично бы вписывалось в модель безопасности
ибо требовало бы SeDebugPrivilege или например SeLoadDriverPrivilege
Второй недостаток — слишком просто ломается — check в одном месте ни проверки кода, нифига
к примеру, на моем SP2 мне понадобилось ровно 8 минут
так что шароварщикам это ни к чему
а вот вирмейкерам бы наоборот эта тема очень пригодилась бы
AWW>>Встроенный механизм который я опубликовал, предназначен исключительно для обеспечения safety... I>Требование и проверка цифровой подписи драйвера в висте это security или safety? Реализовано это требование таким образом, что даже имея административные права нельзя загрузить неподписанный драйвер.
Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...
Здравствуйте, Andrew S, Вы писали:
AS>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...
о каком способе идет речь ? кстати, подпись драйверов, если не ошибаюсь, только на x64 энфорсится
Здравствуйте, Ivan, Вы писали:
I>Здравствуйте, Andrew S, Вы писали:
AS>>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...
I>о каком способе идет речь ? кстати, подпись драйверов, если не ошибаюсь, только на x64 энфорсится
вот здесь кстати описывается один из способов загрузки неподписанных драйверов через pagefile http://theinvisiblethings.blogspot.com/ (тема Vista RC2 vs. pagefile attack ) но эту возможность закрыли в Vista RTM — теперь даже администратор не может напрямую писать на диск.
AS>>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...
I>о каком способе идет речь ? кстати, подпись драйверов, если не ошибаюсь, только на x64 энфорсится
О способе изменения политики проверки подписи путем нахождения нужного хеша непосредственно в setupapi.dll. Насчет х64 не проверял, а на 32-х битной версии способ работает вполне как и раньше. Т.е. все ставится безо всяких вопросов и предупреждений. Вероятно, в х64 они эту схему поменяли, но опять же — слом этого лишь дело времени и желания. За вторым, я думаю, дело не станет, а вот совместными усилиями и первое раздобыть можно
Здравствуйте, Andrew S, Вы писали:
AS>>>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...
AS>О способе изменения политики проверки подписи путем нахождения нужного хеша непосредственно в setupapi.dll. Насчет х64 не >проверял, а на 32-х битной версии способ работает вполне как и раньше. Т.е. все ставится безо всяких вопросов и предупреждений.
мы наверное о разных вещах говорим. помимо предупреждений о подписи драйвера при установке драйвера
на висте x64 ядро отказывается загружать и запускать неподписанные драйверы. например ошибка у регмона выглядит так:
---------------------------
Regmon
---------------------------
Error loading REGMON701: Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.
--------------------------
OK
---------------------------
>Вероятно, в х64 они эту схему поменяли, но опять же — слом этого лишь дело времени и желания. За вторым, я думаю, дело не станет, а >вот совместными усилиями и первое раздобыть можно
возможно какие-то уязвимости о остались, но в целом схема очень продуманная — подпись драйвера проверяется ядром, а к ядру доступа как раз и нет, для критических системных файлов подпись проверяется при загрузке и есть еще PatchGuard, который будет мешать патчить код, проверяющий подпись драйвера.
AS>>>>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...
AS>>О способе изменения политики проверки подписи путем нахождения нужного хеша непосредственно в setupapi.dll. Насчет х64 не >проверял, а на 32-х битной версии способ работает вполне как и раньше. Т.е. все ставится безо всяких вопросов и предупреждений.
I>мы наверное о разных вещах говорим. помимо предупреждений о подписи драйвера при установке драйвера I>на висте x64 ядро отказывается загружать и запускать неподписанные драйверы. например ошибка у регмона выглядит так:
Вероятно. В исходном сообщении про х64 ничего не было, поэтому тут согласен — пока я способов не видел. Но что они будут, можно не сомневаться.
Здравствуйте, Andrew S, Вы писали:
I>>мы наверное о разных вещах говорим. помимо предупреждений о подписи драйвера при установке драйвера I>>на висте x64 ядро отказывается загружать и запускать неподписанные драйверы. например ошибка у регмона выглядит так:
AS>Вероятно. В исходном сообщении про х64 ничего не было, поэтому тут согласен — пока я способов не видел. Но что они будут, можно не сомневаться.
Иван прав, 64 и 32 — две большие разницы
MS специально много вещей не релизило\припасло именно для атаки своих целей и именно на новой платформе (х64).
Так как людям по определению не нравится когда что-то меняется, то такие мощные штуки как перечисленные Иваном — вызвали бы не одну революцию, попытайся их кто протащить в XP в МС не дураки сидят и поэтому они здраво рассудили что ломать не надо, а надо перенести бои на новые, пока еще ничейные, территории и там быстренько все застолбить за собой. технологии захвата тем более уже обкатанные годами
... << RSDN@Home 1.2.0 alpha rev. 655>>
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, Вы писали:
AS>>Вероятно. В исходном сообщении про х64 ничего не было, поэтому тут согласен — пока я способов не видел. Но что они будут, можно не сомневаться. VAB>Иван прав, 64 и 32 — две большие разницы
Да прав, только знаешь Vista и Vista x64 это не синонимы... И когда говоришь про висту х64, пора это уже уточнять...
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Да прав, только знаешь Vista и Vista x64 это не синонимы... И когда говоришь про висту х64, пора это уже уточнять...
в отличие от XP где x64 было частью названия продукта "x64 edition" (и сама XP 64 была основана на коде Server 2003 SP1) , в Vista это уже просто сборка под конкретную платформу x86 или x64 — соответственно, для рядового пользователя при работе разница вообще не будет заметна, лицензия Vista позволяет устанавливать либо x86 либо x64 версию по выбору пользователя.
производители железа для получения WHQL для драйверов должны сразу разрабатывать x86 и x64 версии драйверов — таким образом битность ОС должна со временем иметь все меньшее значение (и в конечном счете должен произойти переход на x64).
поэтому IMO — разрабатывать уже сейчас надо учитывая самые жесткие ограничения (которые присутстствуют только на x64 версии) — PathGuard и принудительную подпись драйверов, иначе о продукте нельзя будет сказать "поддерживает Vista".
Здравствуйте, Ivan, Вы писали:
I>в отличие от XP где x64 было частью названия продукта "x64 edition" (и сама XP 64 была основана на коде Server 2003 SP1) , в Vista это уже просто сборка под конкретную платформу x86 или x64 — соответственно, для рядового пользователя при работе разница вообще не будет заметна, лицензия Vista позволяет устанавливать либо x86 либо x64 версию по выбору пользователя. I>производители железа для получения WHQL для драйверов должны сразу разрабатывать x86 и x64 версии драйверов — таким образом битность ОС должна со временем иметь все меньшее значение (и в конечном счете должен произойти переход на x64). I>поэтому IMO — разрабатывать уже сейчас надо учитывая самые жесткие ограничения (которые присутстствуют только на x64 версии) — PathGuard и принудительную подпись драйверов, иначе о продукте нельзя будет сказать "поддерживает Vista".
Это мы о чем, друг мой? О том чтобы ломали правил придерживаясь... Или вы хотите сказать, что "Требование и проверка цифровой подписи драйвера в висте это security или safety? Реализовано это требование таким образом, что даже имея административные права нельзя загрузить неподписанный драйвер"
Есть 100% верное утверждение? И замечание которое сделал вам Andrew S, сделано не справедливо? И никто до сих под не смог установить неподписанные дрйвера в висту? ...
К чему вы все это написали? Вместо того, чтобы просто, сказать — "да блин, что-то я погорячился с вистой — я х64 имелл ввиду"
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Реализовано это требование таким образом, что даже имея административные права нельзя загрузить неподписанный драйвер"
Простите за не тактный вопрос... а так тогда разработчики железа будут разрабатывать драйвера и отлаживать их, если их не возможно даже загрузить? или нужно подписывать даже дебажный драйвер? пролейте свет пожалуйста.
Здравствуйте, _f_b_i_, Вы писали:
___>Простите за не тактный вопрос... а так тогда разработчики железа будут разрабатывать драйвера и отлаживать их, если их не возможно даже загрузить? или нужно подписывать даже дебажный драйвер? пролейте свет пожалуйста.
Есть специальный ключ загрузки — nointegretychecks — при его установке не проверяются цифровые подписи драйверов при загрузке ( речь идет о Vista x64 ) — это если без геморроя. Если хочется делать все круто — используйте "Signing Drivers for Development and Test (Windows Vista and Later)" — название раздела WDK, если в двух словах — разработчики могут пользоваться специальным тестовым сертификатом.
Здравствуйте, TarasCo, Вы писали:
TC>Есть специальный ключ загрузки — nointegretychecks — при его установке не проверяются цифровые подписи драйверов при загрузке ( речь идет о Vista x64 ) — это если без геморроя.
этот фладок выключили начиная с RC2 и в RTM он не работает. вместо него нужно при каждой загрузке нажимать F8 и выбирать режим “Disable Driver Signature Enforcement” — поэтому второй способ с тестовым сертификатом выглядит более простым
Здравствуйте, Ivan, Вы писали:
I>этот фладок выключили начиная с RC2 и в RTM он не работает. вместо него нужно при каждой загрузке нажимать F8 и выбирать режим “Disable Driver Signature Enforcement” — поэтому второй способ с тестовым сертификатом выглядит более простым
Возможно, Вы правы, но на Vista x64 build 6000 у меня при включенной опции удавались некоторые действия, типа копирования драйвера руками прямо в system32\drivers и потом такие драйвера нормально загружались. Хотя надо сказать, что драйвер был подписан, просто после ребилда он не соответствовал cat файлу, указанному в inf е при установке. По идее, он не должен был бы загружаться? Сказать по чести, я специально вопрос не исследовал. В любом случае, разработчики имеют возможность разрабатывать драйвера под x64. Кроме того, по-моему при загрузке в отладочном режиме при присутствии отладчика ядра неподписанные драйвера также загружаются?
Да пребудет с тобою сила
Re[13]: Блокировка запуска приложений
От:
Аноним
Дата:
24.01.07 10:28
Оценка:
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Предположим в вашей системе есть два устройства IDE один жёсткий диск и сд-ром...
AWW>Воспользуемся WinObjEx, если вам так больше нравиться -
AWW>находим в "\Device\Ide"
AWW>\Device\Ide\IdeDevicePOT1L0-c — CD-ROM Drive AWW>\Device\Ide\IdeDevicePOT1L0-4 — Disk Drive
AWW>Устанавливаем для устройства \Device\Ide\IdeDevicePOT1L0-c "Deny" "execute", для пользователя «aaa».
AWW>запускаем "Commаnd Prompt"
AWW>c:\> dir d:
AWW>конечно если у вас cd-rom это "D:"
AWW>видим содержимое диска, то есть для администратора запрета нет — все работает.
AWW>В запускаем RunAs /user:aaa /noprofile cmd.exe
AWW>с:\>dir d:\
AWW>Access is denied.
AWW>Ок. Что и требовалось...
AWW>///////////////////////////////////////////////////////////////////
Здравствуйте, TarasCo, Вы писали:
TC>Возможно, Вы правы, но на Vista x64 build 6000 у меня при включенной опции удавались некоторые действия, типа копирования >драйвера руками прямо в system32\drivers
проверка подписи как я понимаю влияет только на загрузку и запуск драйвера. при установке выдается предупреждение о том, что подписи нет — но такой драйвер все равно установить можно. правда работать он не будет
мне попадалось мнение, что опцию nointegritycheck убрали из-за того, что ее можно было бы включить программно -> этим моментально могли бы воспользоваться руткиты для обхода проверки подписи (хотя потребовался бы ребут компьютера). а вот если включить тестовый режим testmode (попдись драйвера тестовым сертификатом) — то по углам экрана будет надпись о том, что система загружена в тестовом режиме — и пользователь заметит, что что-то не так, если эту опцию включил не он.
>и потом такие драйвера нормально загружались. Хотя надо сказать, что драйвер был подписан, просто после ребилда он не >соответствовал cat файлу, указанному в inf е при установке. По идее, он не должен был бы загружаться?
насколько я понял, подписан может быть либо сам файл с драйвером, либо хеш файла должен быть в cat'е. видимо, если в файле sys есть подпись и она валидная, cat уже не проверяется.
>Сказать по чести, я специально вопрос не исследовал. В любом случае, разработчики имеют возможность разрабатывать драйвера под >x64. Кроме того, по-моему при загрузке в отладочном режиме при присутствии отладчика ядра неподписанные драйвера также загружаются?
по-моему, да. когда подключен kernel отладчик — проверка подписи не будет энфорситься и PatchGuard выключается.
Здравствуйте, Аноним, Вы писали:
А>Вы проверяли, это действительно работает ?
я не проверял — но не должно работать при запросах внутрь нейсмспейса девайса единственное на что можно повлиять его security descriptor'ом — это FILE_TRAVERSE, т.е. право траверсить неймспейс девайса. если этого права нет — будет запрещен любой доступ внутрь нейсмпейса — на чтение, запись, выполнение и т.п.
так как значения FILE_TRAVERSE и FILE_EXECUTE совпадюат, то можно подумать, что deny на execute мешет выполнять файлы
реально в приведенном примере блокируется любой доступ к нейспейсу устройства. хотя в каком-то смысле, это блокирует запуск приложений в том числе .
и еще одно замечание, в Vista FILE_TRAVERSE больше не влияет на возможность траверсить нейспейс волюмов. дело здесь в том, что право FILE_TRAVERSE не учитывается когда включена привилегия SeChangeNotify, эта привилегия по умолчанию есть у всех пользтвателей, но для устройств-дисков в ОС до Vista было сделано исключение и все равно проверялось право FILE_TRAVERSE. В Vista это больше не работает — т.е. FILE_TRAVERSE не учитывается при включенной привилегии и на дисках в том числе.
Работает.
I>я не проверял — но не должно работать при запросах внутрь нейсмспейса девайса единственное на что можно повлиять его security descriptor'ом — это FILE_TRAVERSE, т.е. право траверсить неймспейс девайса. если этого права нет — будет запрещен любой доступ внутрь нейсмпейса — на чтение, запись, выполнение и т.п.
Ну это всего ли шь ваше скромное мнение, а практика как известно критерий истины... Понятно, что обидно признаветь, но факт есть факт...
Что касается ... ваших рассуждений об FILE_TRAVERSE, то запрет на выполнение сделано исплючительно для удобства в понимании Сергею, поставьте отказ на чтение и получите тоже, что и с этим... Да много, так чего можно сделать... И перестаньте теоретизировать, а то опять случится какой нибудь конфуз...
I>так как значения FILE_TRAVERSE и FILE_EXECUTE совпадюат, то можно подумать, что deny на execute мешет выполнять файлы
ну-ну...
I>реально в приведенном примере блокируется любой доступ к нейспейсу устройства. хотя в каком-то смысле, это блокирует запуск приложений в том числе .
Так, чего не так то! Запустить нельзя! Всё... что я говорил то и есть, что просили то и получили...
I>и еще одно замечание, в Vista FILE_TRAVERSE больше не влияет на возможность траверсить нейспейс волюмов. дело здесь в том, что право FILE_TRAVERSE не учитывается когда включена привилегия SeChangeNotify, эта привилегия по умолчанию есть у всех пользтвателей, но для устройств-дисков в ОС до Vista было сделано исключение и все равно проверялось право FILE_TRAVERSE. В Vista это больше не работает — т.е. FILE_TRAVERSE не учитывается при включенной привилегии и на дисках в том числе.
Да оставьте вы в покое атрибут выполнения, он не только в висте это означет, а и в юниксе например тоже... Хватит и не разрешения чтени, я блин уже устал это повторять!
И прежде, чем что либо на 100% утвердждать или опровергать, рекомендую проверять... А то можно, попросту потом можно опять начать плакать про то, что "прикалываются"
Здравствуйте, Andrew.W Worobow, Вы писали:
I>>я не проверял — но не должно работать при запросах внутрь нейсмспейса девайса единственное на что можно повлиять его security descriptor'ом — это FILE_TRAVERSE, т.е. право траверсить неймспейс девайса. если этого права нет — будет запрещен любой доступ внутрь нейсмпейса — на чтение, запись, выполнение и т.п.
AWW> Ну это всего ли шь ваше скромное мнение, а практика как известно критерий истины... Понятно, что обидно признаветь, но факт есть факт...
Иван абсолютно прав. Единственный случай, когда security descriptor устройства учитывается при проверке прав доступа к объектам внутри пространства имен устройства, — это наличие флага FILE_DEVICE_SECURE_OPEN в характеристиках устройства. Но устройства, представляющие тома файловых систем, по вполне понятным причинам такого флага не имеют. Так что факты не на вашей стороне.
AWW>Что касается ... ваших рассуждений об FILE_TRAVERSE, то запрет на выполнение сделано исплючительно для удобства в понимании Сергею, поставьте отказ на чтение и получите тоже, что и с этим... Да много, так чего можно сделать... И перестаньте теоретизировать, а то опять случится какой нибудь конфуз...
Ну тут уже можно вам посоветовать проверить все ручками. В приведенном примере запретите все, кроме исполнения, и вы получите полный доступ к файлам на томе.
I>>так как значения FILE_TRAVERSE и FILE_EXECUTE совпадюат, то можно подумать, что deny на execute мешет выполнять файлы
AWW>ну-ну...
Еще что-нибудь по существу есть сказать?
I>>реально в приведенном примере блокируется любой доступ к нейспейсу устройства. хотя в каком-то смысле, это блокирует запуск приложений в том числе .
AWW>Так, чего не так то! Запустить нельзя! Всё... что я говорил то и есть, что просили то и получили...
Попытавшись запретить доступ на исполнение, вы махом запретили полный доступ. Это не совсем то, что нужно, мягко говоря
AWW>Да оставьте вы в покое атрибут выполнения, он не только в висте это означет, а и в юниксе например тоже... Хватит и не разрешения чтени, я блин уже устал это повторять!
Можно вообще компьютер не включать, этого тоже вполне хватит.
Здравствуйте, Ivan, Вы писали:
I>я не проверял — но не должно работать при запросах внутрь нейсмспейса девайса единственное на что можно повлиять его security descriptor'ом — это FILE_TRAVERSE, т.е. право траверсить неймспейс девайса.
немного официальной информации на эту тему здесь: http://www.microsoft.com.nsatc.net/whdc/driver/security/drvsecure.mspx
To create a file, a process must have traversal rights to the parent directories in the target path. For example, to create \Device\Floppy0\Directory\File.txt, a process must have the right to traverse \Device, \Device\Floppy0, and \Device\Floppy0\Directory. The I/O Manager checks only the traversal rights for these directories.
единственное, что мне непонятно — является ли багом или фичей то, что в Vista отбирание FILE_TRAVERSE больше не работает
формально все правильно, так как у любого юзера есть привилегия bypass traverse check, но реально под угрозой совеместимость приложений, которые пользовались этой функциональностью
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>Иван абсолютно прав. Единственный случай, когда security descriptor устройства учитывается при проверке прав доступа к объектам внутри пространства имен устройства, — это наличие флага FILE_DEVICE_SECURE_OPEN в характеристиках устройства. Но устройства, представляющие тома файловых систем, по вполне понятным причинам такого флага не имеют. Так что факты не на вашей стороне.
Иван, этого не говорил, это я вам говорил, когда предлагал почитать про IoCreateDeviceSecure... Иван, говорит про то, что запрет на выполнение, а для директории это FILE_TRAVERSE... И про то что отсутствие этого права на любой обьект в пути не дает доступа к обьекту самому... Ну на самом деле это верно и с этим никто не спорит. И эту проверку между прочим можно отменить, если мне память не изменяет ... Но не суть.
SS>Ну тут уже можно вам посоветовать проверить все ручками. В приведенном примере запретите все, кроме исполнения, и вы получите полный доступ к файлам на томе.
Запретил, НО и не разрешил FILE_EXECUTE, доступа нет. НЕ запрещал ничего кроме удаления, но и не разрешал выполнение — доспупа нет, ну я ничего другого и не ожидал...
SS>Еще что-нибудь по существу есть сказать?
Не разрешает, раз доступа к диску нет, то и не запустишь. Все сделано в рамках безопасности. чтд. КОНЕЧНО, и тут вы правы, а я нет, НАСЛЕДОВАНИЕ здесь не так просто организовать... Но и тут нет ничего не возможного.
I>>>реально в приведенном примере блокируется любой доступ к нейспейсу устройства. хотя в каком-то смысле, это блокирует запуск приложений в том числе .
ну-ну — вот-вот.
AWW>>Так, чего не так то! Запустить нельзя! Всё... что я говорил то и есть, что просили то и получили...
SS>Попытавшись запретить доступ на исполнение, вы махом запретили полный доступ. Это не совсем то, что нужно, мягко говоря
Нормально, ибо — нехрен... Надо чего юзеру — пусть просит у админа. На мой взгляд, это нормально. Ибо вы же сами хотели — "замкнутая программная среда"
SS>Можно вообще компьютер не включать, этого тоже вполне хватит.
Нет, не надо передёргивать — это другое... Это только степень чувствительности к ограничению свобод.
а вот здесь кстати разясняется разница между FILE_LIST_DIRECTORY и FILE_TRAVERSE ... Но это скоре МС сам-себя типа учит... Access Mask
Всё, господа, мне кажется тема себя полностью исчерпала, ну я покрайней мере не хочу больше тратить на неё время, которого и так катострофически ни на что не хватает. Было приятно поучавствовать, надеюсь мои "приколы" никого смертельно не обидели...
Здравствуйте, Andrew S, Вы писали:
AS>Но что они будут, можно не сомневаться.
пока способа нет, вот и Alex Ionescu об этом написал в своем блоге. http://www.alex-ionescu.com/?p=24
Re: 2 в 1: Блокировка запуска приложений и WLNP. Test App.
От:
Аноним
Дата:
10.05.11 09:04
Оценка:
VAB>
краткая инструкция: кладем wlnp.dll в %systemroot%\system32. Если хотим тестить WLNP — пускаем wlnp.reg, если хотим тестить блокировку приложений, регистрируемся через AppCertDlls.reg. Reboot. Достаем DbgView/WinDbg и смотрим логи. Для проверки пытаемся дернуть notepad.exe — навскидку решил блокировать все что имеет слово notepad в пути. Смотрим на экран и в лог.
На x32 всё работает, как описано — записная книжка не запускается. После перекомпиляции библиотеки на x64 на Win2008 SP2 работает так же, за одним исключением — если запускать notepad из far-а, то библиотека не вызывается и notepad стартует.
VAB>
имеет смысл попробовать сложить 2 либы: 64-бит в system32 и 32-бит в SysWOW64 и запустить notepad из FAR еще раз.
Да, спасибо, помогло. Когда из FAR-а запускаешь start notepad, то вызывается 64-х разрядная библиотека, а когда просто notepad, то 32-х.
Re[2]: 2 в 1: Блокировка запуска приложений и WLNP. Test App
От:
Аноним
Дата:
10.05.11 10:01
Оценка:
Здравствуйте, Аноним, Вы писали:
VAB>>
краткая инструкция: кладем wlnp.dll в %systemroot%\system32. Если хотим тестить WLNP — пускаем wlnp.reg, если хотим тестить блокировку приложений, регистрируемся через AppCertDlls.reg. Reboot. Достаем DbgView/WinDbg и смотрим логи. Для проверки пытаемся дернуть notepad.exe — навскидку решил блокировать все что имеет слово notepad в пути. Смотрим на экран и в лог.
А>На x32 всё работает, как описано — записная книжка не запускается. После перекомпиляции библиотеки на x64 на Win2008 SP2 работает так же, за одним исключением — если запускать notepad из far-а, то библиотека не вызывается и notepad стартует.
VAB>>
имеет смысл попробовать сложить 2 либы: 64-бит в system32 и 32-бит в SysWOW64 и запустить notepad из FAR еще раз.
А>Да, спасибо, помогло. Когда из FAR-а запускаешь start notepad, то вызывается 64-х разрядная библиотека, а когда просто notepad, то 32-х.
Следующая трудность если запускать Run as administrator, то управление опять библиотекам не передаётся.
Re[3]: 2 в 1: Блокировка запуска приложений и WLNP. Test App
А>>На x32 всё работает, как описано — записная книжка не запускается. После перекомпиляции библиотеки на x64 на Win2008 SP2 работает так же, за одним исключением — если запускать notepad из far-а, то библиотека не вызывается и notepad стартует.
VAB>>>
имеет смысл попробовать сложить 2 либы: 64-бит в system32 и 32-бит в SysWOW64 и запустить notepad из FAR еще раз.
А>>Да, спасибо, помогло. Когда из FAR-а запускаешь start notepad, то вызывается 64-х разрядная библиотека, а когда просто notepad, то 32-х.
А>Следующая трудность если запускать Run as administrator, то управление опять библиотекам не передаётся.
Что говорит Process Monitor?
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.
L>Юзера которых надо урезать в правах — понятно прав локального админа не имеют.
Отсутствия "прав локального админа" еще не все. Надо еще понимать, что гарантированно это все будет работать только в случае жесткого whitelisting'а исполняемых файлов (и не только ехе). Whitelisting нужен дабы злой юзер не мог исполнить код, который запустит "хороший" процесс и использует его в качестве лоадера для "плохого", причем лоадер просто тупо выделит PAGE_EXECUTE* странички и разложить в них содержимое злого ехе. Без этого глупо рассуждать о сферической крутости перехвата PspCreateProcess вместо Zw*CreateProcess* или фильтра над FS.
Как много веселых ребят, и все делают велосипед...
O>Надо еще понимать, что гарантированно это все будет работать только в случае жесткого whitelisting'а исполняемых файлов (и не только ехе). Whitelisting нужен дабы...
Тссс, ты что! Беду накликаешь же! Сейчас прибежит злобный Andrew.W Worobow и расскажет, какие мы тут все мудаки и как он запустит злонамеренный код в обход всех твоих списков и прочей бодяги. Перечитай тему полностью, если ещё не сделал этого. И вообще, народ, не трогайте эту тему, я вас прошу, моя нежная психика не выдержит ещё одного зубодробительного цирка. Уж лучше новую тему создайте.
А по мне так пусть придет Воробов и скажет свое мнение. И нечего людям рот закрывать.
То что Воробов где-то там ошибся когда-то, не говорит о том что он ошибается всегда.
В споре рождается истина. А еще, история показывает, что все споры ученых мужей
с таким вот перехедом на личности всегда тормозил научно-технический прогресс.
Приводите лучше примеры и факты чем таки сентименты.
МС ещё в далеком уже и не помню каком году, предлагал спец. тулузу... Которая кстати, построена на схожей с изначальной идее... 
. Вот если бы томы не монтировались автоматически, а на подобие UNIX требовали команды mount, а для исполнения команды нужны были бы административные привилегии, вот бы было всем счастье 
Это вы все время с файлами боретесь, вместо того чтобы, один раз и до конца разобраться с моделью безопасности WINDOWS.
Вы простите про что? Я вот уже почти 15 лет как занимаюсь системным программированием и не знал, что есть какая-то ОСОБАЯ процедура (Наверное в ядре 
) которая "запускает" 
А как-же "фундамент".
если запускать Run as administrator, то управление опять библиотекам не передаётся.
