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

C>>>Задача такая — нужно написать фильтр-драйвер, который запретит доступ к веб-камере
VAB>>что есть доступ к веб-камере?
C>Проще говоря, не авторизированные приложения не должны иметь возможность получать видеопоток и передавать его.
это все понятно, я спросил лишь — Вы уже идентифицировали точку\ресурс, который предоставляет приложениям "возможность получать видеопоток и передавать его"?

насколько я понимаю, в конце цепочки должен быть драйвер\девайс и\или их набор (фильтры) — потому и совет ниже про инструменты для исследования таких цепочек.

VAB>>ресурс, ответственный за веб-камеру еще нужно идентифицировать и найти — это должен быть вполне конкретный девайс, WinObj(Ex) \ devview и т.п. инструменты подскажут.

сам я не занимался пока плотно такого рода драйверами, посему и не могу сразу сказать точно (а предпологать не буду, дабы никого не сбивать с панталыку) какие именно драйвера у нас за это дело ответственные и поставляются с ОС (будьте готовы к тому что под разные ОС — разная архитектура, в XP что-то менялось точно по сравнению с 2000й, выше XP — уже не знаю), а что предоставляется производителем железки (если). Раздел в DDK Video Capture Devices: Windows DDK весьма обширен.

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

короче, надо Вам брать инструменты в руки и разбираться куда в итоге нужно сажать фильтр(ы) — забыл еще DevTree и IrpTracker упомянуть — тоже пригодятся для отслеживания топологии соотв. стека и идентификации защищаемого девайса. IrpTracker пожалуй даже самый быстрый вариант — натравите на реально работающую камеру и все увидите.


Ну и будем надеяться, коллеги с нужным опытом объявятся и дополнят\поправят — если Вы сами не отпишитесь вперед

C>>>всем приложениям, кроме определенных (разрешенных админом).
VAB>>далее встает вопрос, что есть trusted приложение, а что нет — как планирует админ различать?
C>Это проблема (и не простая), которую также нужно решить, пока не знаю.

C>Возможно, использовать подписи, название, контрольную сумму выполняемого модуля, что-то еще?
Вы правы, вариантов масса. Начиная с идентификации по имени \ пути executable файла. Которая даст кучу проблем.

пример: что, если я скопирую приложение c:\trusted.exe в c:\untrusted.exe — должны ли оба иметь доступ к веб-камере?
А если наоборот, переименую c:\untrusted.exe в c:\trusted.exe и что тогда должно быть при запуске c:\trusted.exe?

Все эти проблемы начинаются потому что в NT, когда речь идет о безопасности какого-либо ресурса, лучше не опираться на доступ из под определенного процесса (т.к. есть масса способов это дело обойти, внедрившись в нужный процесс и выполняя работу из под него и т.п.), а из-под определенного пользователя.

Криптограница проходит не на уровне процессов, нужно переходить к trustee (пользователи, группы, комппьютеры).

Но без ТЗ нельзя отсекать и такие варианты тоже. Иногда важно сделать быстро, пусть и не очень секурно и т.п.

VAB>>возможно, стоит подумать о доступе к ресурсу со стороны опреденных trustees (пользователи, группы, компы), а не приложений, т.к. в этом случае NT security модель будет работать на вас. С приложениями все не так просто окажется.

C>Ситуация как раз такая, что заказчик не доверяет ни одному из своих пользователей. Т.е. у пользователя должна быть установлена камера на рабочем месте, он должен использовать ее ТОЛЬКО с нашим приложением (приложениями), никакие другие приложения для этого пользователя не могут использовать камеру.
да было ясно сразу, куда ветер дует... что ж, задача упирается в проблему однозначной идентификации процессов и в итоге executables.

ок, давайте быстро прикинем по Вашим вариантам: с контрольной суммой. Это будет работать.

Равно как и с подписью — если Вы сумеете подписать приложения своим сертификатом (или они уже подписаны производителем как надо — тогда вообще класс, ибо вопросы ниже отпадают) и затем будете проверять его наличие и валидность.

Подпись может быть перспективнее, чем CRC — а может быть и нет: просто тут встают проблемы чуть иного уровня — смотрите, как распространять такие подписанные Вами приложения клиентам, как быть если вышел неподписанный апдейт\новая версия приложения?

В случае подписи тут будет нужна переподпись апдейта и доставка переподписанного приложения до клиента.
В случае CRC тут будет нужен пересчет и доставка новых CRC до драйвера на клиентах.

какой вариант (наверняка есть и иные и варианты и проблемы) предпочтительнее — без ТЗ и знания Вашей ситуации (кто заказчики, насколько серьезный уровень им нужен, сроки\бюджет и т.п.) вряд ли можно сказать.