AS>>>>Слишком сильное утверждение, чтобы быть правдой. Загрузить можно, причем ровно тем же способом, что и в ХР. По крайней мере, я в ультимате такого добился безо всяких проблем...

AS>>О способе изменения политики проверки подписи путем нахождения нужного хеша непосредственно в setupapi.dll. Насчет х64 не >проверял, а на 32-х битной версии способ работает вполне как и раньше. Т.е. все ставится безо всяких вопросов и предупреждений.

I>мы наверное о разных вещах говорим. помимо предупреждений о подписи драйвера при установке драйвера
I>на висте x64 ядро отказывается загружать и запускать неподписанные драйверы. например ошибка у регмона выглядит так:

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

Здравствуйте, Andrew S, Вы писали:

I>>мы наверное о разных вещах говорим. помимо предупреждений о подписи драйвера при установке драйвера
I>>на висте x64 ядро отказывается загружать и запускать неподписанные драйверы. например ошибка у регмона выглядит так:

AS>Вероятно. В исходном сообщении про х64 ничего не было, поэтому тут согласен — пока я способов не видел. Но что они будут, можно не сомневаться.
Иван прав, 64 и 32 — две большие разницы

MS специально много вещей не релизило\припасло именно для атаки своих целей и именно на новой платформе (х64).

Так как людям по определению не нравится когда что-то меняется, то такие мощные штуки как перечисленные Иваном — вызвали бы не одну революцию, попытайся их кто протащить в XP в МС не дураки сидят и поэтому они здраво рассудили что ломать не надо, а надо перенести бои на новые, пока еще ничейные, территории и там быстренько все застолбить за собой. технологии захвата тем более уже обкатанные годами

Здравствуйте, 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. Кроме того, по-моему при загрузке в отладочном режиме при присутствии отладчика ядра неподписанные драйвера также загружаются?

Здравствуйте, 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 не учитывается при включенной привилегии и на дисках в том числе.

Здравствуйте, Ivan, Вы писали:


А>>Вы проверяли, это действительно работает ?

Работает.

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>Можно вообще компьютер не включать, этого тоже вполне хватит.

Нет, не надо передёргивать — это другое... Это только степень чувствительности к ограничению свобод.

Да кстати посмотрите вот на этот раздел Security Considerations for File Systems

и в часности на эту страницу — File System Security Issues

а вот здесь кстати разясняется разница между FILE_LIST_DIRECTORY и FILE_TRAVERSE ... Но это скоре МС сам-себя типа учит... Access Mask



Всё, господа, мне кажется тема себя полностью исчерпала, ну я покрайней мере не хочу больше тратить на неё время, которого и так катострофически ни на что не хватает. Было приятно поучавствовать, надеюсь мои "приколы" никого смертельно не обидели...

Здравствуйте, Andrew S, Вы писали:

AS>Но что они будут, можно не сомневаться.
пока способа нет, вот и Alex Ionescu об этом написал в своем блоге.
http://www.alex-ionescu.com/?p=24

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-х.

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

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, то управление опять библиотекам не передаётся.

А>>На 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?