Перейти к содержанию
ASteZ

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

Recommended Posts

ASteZ

Настраиваю у себя на ноутбуке "политики" (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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
WindowsNT

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

  • Upvote 5

Поделиться сообщением


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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
WindowsNT

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

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

  • Upvote 5

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
ASteZ
Агентство Национальной Безопасности США (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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
dkarab

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

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

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

Поделиться сообщением


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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
ASteZ
А зачем нужны тогда правила SRP? Когда что лучше использовать?

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

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

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

Поделиться сообщением


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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Илио́н

Система 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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
WindowsNT

Проблема возникает на стыке технологий — например, когда х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
Вспомнилось. В Гугл: Vadims Podans' blog - AppLocker vs Software Restriction Policies

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Илио́н

WindowsNT

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

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

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

C:\Program Files

заработало.

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

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

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

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

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

C:\Windows

C:\Program Files

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
WindowsNT

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Илио́н

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Илио́н

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • Ego Dekker
    • ArktiTig
      Арктика - северная полярная область Земли, включающая окраины материков Евразии и Северной Америки, почти весь Северный Ледовитый океан с островами и прилегающие к нему части Атлантического и Тихого океанов. Название её происходит от греческого слова arctos (медведь) и связано со звёздами: Полярная звезда, находящаяся почти точно в зените над Северным полюсом, принадлежит к созвездию Малая Медведица.
    • ArktiTig
      Арктика - северная полярная область Земли, включающая окраины материков Евразии и Северной Америки, почти весь Северный Ледовитый океан с островами и прилегающие к нему части Атлантического и Тихого океанов. Название её происходит от греческого слова arctos (медведь) и связано со звёздами: Полярная звезда, находящаяся почти точно в зените над Северным полюсом, принадлежит к созвездию Малая Медведица.
    • PR55.RP55
      .xml  файлы taskschd.msc Могут быть подписаны  цифровой подписью. Думаю будет нелишним, если uVS будет это фиксировать. т.е. проверять не только подпись целевого файла, но и подпись самого файла\задачи. и писать в ИНфО .  
    • demkd
      ---------------------------------------------------------
       4.15.2
      ---------------------------------------------------------
       o Исправлена ошибка при работе с образом автозапуска.
         Для некоторых процессов команда unload не добавлялась в скрипт при нажатии кнопки "принять изменения".  o Добавлена плашка окна на таскбаре для окна удаленного рабочего стола.
         (при работе с удаленной системой) -----------------------------------------------------------
      Есть проблема с локализацией глюка в редких случаях приводящему к аварийному завершению uVS при активном флаге "Проверять весь HKCR".
      На основе дампов его найти не получается, нужна копия реестра системы с такой проблемой, если кому-то попадется такая проблема, то присылайте архив с копией реестра системы мне на почту.  
×