Вопрос по настройке "политики ограниченного использования программ"

[ASteZ 0]

Настраиваю у себя на ноутбуке "политики" (Win7 64bit)

Настроил правила пути для запускаются программ только из "program files" и windows..

Теперь странность..

Запускаю программу из командной строки.. Она нормально запускается.

Запускаю ее-же из под far - "неопознанная ошибка, can not execute..."

Если запускаю из под Far как cmd /c имя-программы -все работает

если в "политиках" изменяю ууровень по умолчанию на "неограниченный" то опять таки все работает нормально, эффект возникает именно из за "политик"

Вопрос собственно в том как это исправить и от чего так происходит?

Вторая странность - у меня наотрез отказывался запускаться NetBeans пока я не прописал в дополнение к общим путям на program files

отдельное правило пути для C:\Program Files\Java

Вопрос в том, чем вызван такой эффект?

Правила пути к program files прописаны так:

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

[ASteZ 0]

upd (уточнение): проблема возникает при запуске 64битной программы из командной строки 32-х битного Far-а, 32-х битные программы запускаются без проблем.

[WindowsNT 100]

Хорошее уточнение, оно показывает корень проблемы. Система неверно обрабатывает раздельные пути Program Files для 32- и 64-разрядных программ. Опишите тогда пути к Program Files не ключами реестра, как сейчас, а просто напрямую как папки.

[ASteZ 0]

Хорошее уточнение, оно показывает корень проблемы. Система неверно обрабатывает раздельные пути Program Files для 32- и 64-разрядных программ. Опишите тогда пути к Program Files не ключами реестра, как сейчас, а просто напрямую как папки.

Ага, заработало.. И отдельный путь к java когда после того убрал без последствий...

Тогда вопрос - почему так получается?

Ведь и 32-х битные и 64-х битные приложения по отдельности запускались нормально...

Пути заданные ключами реестра я так понимаю можно безболезненно убрать в таком случае?

И еще маленький вопросик - вроде бы есть некоторое количество подпапок в windows с правами обычного пользователя на запись..

Типа system32\debug, system32\catroot2\

Запуск из этих 2-х я запретил явно.. А нет нигде какого-нибудь списка какие подпапки из windows еще стоит "прикрыть" от запуска из них приложений?

[WindowsNT 100]

Агентство Национальной Безопасности США (NSA) дало несколько мыслей по этому поводу - http://www.nsa.gov/ia/_files/os/win2k/Appl...g_Using_SRP.pdf

Я сам выводил системную папку Temp за пределы Windows и переводил Print Spooler на другой диск. Особо заморачиваться не стоит, мне кажется. Однако, убедитесь, что включён фильтр DLL-модулей, это мера защиты номер раз от запуска DLL через команду rundll и от DLL Hijacking.

[ASteZ 0]

Агентство Национальной Безопасности США (NSA) дало несколько мыслей по этому поводу - http://www.nsa.gov/ia/_files/os/win2k/Appl...g_Using_SRP.pdf

Я сам выводил системную папку Temp за пределы Windows и переводил Print Spooler на другой диск. Особо заморачиваться не стоит, мне кажется. Однако, убедитесь, что включён фильтр DLL-модулей, это мера защиты номер раз от запуска DLL через команду rundll и от DLL Hijacking.

Спасибо. Я его отключил в свое время из за того что отказывался запукаться NetBeans (видимо оно было из за некорректной отработки пути через регистри)

После того как включил - пришлось еще добавить правила хэша для CheckPoint SSL Network Extender который запускает свою jni dll через temp. И ведь фиг найдешь из за чего проблема - в журнале никаких следов не было..

[WindowsNT 100]

Для подробного отчёта исполнения правил SRP, включая обработку dll, нужно включить журналирование в реестре:

HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers

REG_SZ 'LogFileName'=”C:\Windows\SRP.log”

[dkarab 0]

Мы в свое доменчике для блокировки "стороннего" софта используем AppLocker через групповые политики (вариант испоьзования описан тут).

А зачем нужны тогда правила SRP? Когда что лучше использовать?

Или лучше всего использовать одновременно и AppLocker и Software Restriction Policy?

[Dr. Faust 62]

Мы в свое доменчике для блокировки "стороннего" софта используем AppLocker через групповые политики (вариант испоьзования описан тут).

А зачем нужны тогда правила SRP? Когда что лучше использовать?

Или лучше всего использовать одновременно и AppLocker и Software Restriction Policy?

Если вы уже используете AppLocker, то SRP вам уже вряд ли нужны.

[ASteZ 0]

А зачем нужны тогда правила SRP? Когда что лучше использовать?

Если я правильно понял то AppLocker работает по принципу "черного списка" запрещая запуск определенных программ..

Правила SPR работают по принципу запрещения запуска всего что не разрешено в явном виде .. Реализуя по своей сути "белый список"..

С точки зрания безопасности ИМХО правила SRP надежнее..

[WindowsNT 100]

Если я правильно понял то AppLocker работает по принципу "черного списка" запрещая запуск определенных программ..

Правила SPR работают по принципу запрещения запуска всего что не разрешено в явном виде .. Реализуя по своей сути "белый список"..

С точки зрания безопасности ИМХО правила SRP надежнее..

Это не совсем так.

AppLocker является чистым Application Whitelisting даже по умолчанию, в то время как SRP по умолчанию включается в режиме Blacklisting.

С другой стороны, AppLocker сложнее управляется (например, он ну никак не понимает сетевые пути UNC) и доступен только на версии Ultimate/Enterprise.

Я использую SRP, так как оно работает в смешанной сети (XP/Vista/7) и имеется начиная с редакции Professional. И понимает сетевые пути. Но обойти SRP проще.

[Илио́н 20]

Система 64-bit.

По умолчанию в "Дополнительных правилах" SPR прописаны два пути:

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Я не силён в этой орфографии, но понял, что по умолчанию совсем не подразумевали 32-битные приложения?! Вопрос почему? Или когда создавали Windows-64 уже не думали, что 32-bit приложения ещё имеют право на жизнь. Ну да ладно не суть.

Прописал путь так (и так получилось):

C:\Program Files (x86)

И мой FF поехал в интернет тогда.

Что ещё интересно когда смотришь свойства двух вышеупомянутых объектов, то путь выводится либо как есть (смотри выше), либо просто как обычный путь (как-то через раз получается):

C:\Windows

C:\Program Files

Интересные дела.

И чем в корне отличается Уровень безопасности "Неограниченный" от "Обычный пользователь" для нового создаваемого правила?

Как корректнее прописать путь к C:\Program Files (x86) и есть ли вообще разница в этом?

Какие ещё пути можно без опаски прописать, с оглядкой на будущее для среднестатистического пользователя и нормального функционирования программ? Для нормального функционирования различных программ (требующих подзагрузки .dll и т.д.). Или это дело сугубо интимное, в зависимости от используемых программ?

А то ведь можно упереться в незапускающее приложение, а смотреть куда и что ему требуется, в общем-то я так понимаю и не куда, то есть в смысле где и что.

Ведь политика применена и к .dll-кам в том числе. Да и не только.

Уже половина программ не запускается.

Что интересно некоторые без уведомления от системы о наложении ограничения. А действительно, есть методика по поиску на какие именно вещи был наложен запрет. В просмотре событий как-то не особо разгуляешься. Лог предложенный выше в теме создал и он ведётся. Может он чем-то помочь?

Это конечно замечательно. Теперь надо искать чего они хотять...

[WindowsNT 100]

Проблема возникает на стыке технологий — например, когда х86-программа из-под себя вызывает х64- и наоборот. Поэтому для 64-разрядных систем нужно вручную добавить правило %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%. Но в реальной среде я не мудрю, пишу прямо C:\Program Files и C:\Program Files (x86), это работает надёжнее.

Уровень безопасности "Обычный пользователь" принуждает указанные программы запускаться только с ограниченными привилегиями. Но! это работает только в Vista. Жаль, но в семёрке они этот режим убрали.

Пути зависят от конкретной программы. Например, некоторые программы генерируют и запускают DLL из %Temp%, приходится такие случаи индивидуально отлавливать и либо разрешать хэши, либо конкретные имена файлов. Но таких программ очень мало. В основном, всё прекрасно работает либо из Program Files, либо из путей типа C:\MegaSuperSoftware. Похоже, вы делали политику у себя по какой-то другой инструкции.

[UIT 103]

Вспомнилось. В Гугл: Vadims Podans' blog - AppLocker vs Software Restriction Policies

[Илио́н 20]

WindowsNT

Win_7x64 и там и там (хост\гость).

Настраивал по статье.

После того, как прописал явно:

C:\Program Files

заработало.

Ещё покатаю - перенесу в хост.

Недопонимаю (может не хватает знаний):

Проблема возникает на стыке технологий — например, когда х86-программа из-под себя вызывает х64- и наоборот.

А с учётом этого тем более:

Что ещё интересно когда смотришь свойства двух вышеупомянутых объектов, то путь выводится либо как есть (смотри выше), либо просто как обычный путь (как-то через раз получается):

C:\Windows

C:\Program Files

[WindowsNT 100]

Типичный пример, когда разрядность вызывает проблему:

Вы пытаетесь открыть из MS Outlook (x64) приложенный файл .pdf, открываемый через Adobe Reader (x86. У Outlook-а и Reader-а при этом возникает путаница с переменной %ProgramFilesDir%, SRP блокирует запуск Adobe. А если приложенный файл сохранить и открыть отдельно, проблемы нет.

Просто пропишите оба два пути до Program Files в политику, и всё.

[Илио́н 0]

А в XP такая настройка присутствует? В каких версиях, паках. Или чем заменить подобным, стандартные есть средства?

[Илио́н 0]

На свой вопрос ответ нашёл. Через командную строку можно удалить политику SPR?