Почему моя политика WDAC, созданная на основе журналов Event Viewer с правилом FilePath, не работает?

Я пытаюсь понять, почему моя политика WDAC не позволяет программам, которые я добавил в список разрешений, используя журналы Event Viewer, запускаться.

Вот как я создал список разрешений для политики WDAC на основе журналов аудита Event Viewer:

New-CIPolicy -FilePath .\EventsPolicy.xml -Audit -Level FilePath –UserPEs -UserWriteablePaths -MultiplePolicyFormat 3> .\EventsPolicyWarnings.txt

Я хочу использовать только FilePath, потому что тогда политику не нужно будет обновлять, когда программы обновляются до новых версий.

Некоторые части, ответственные за список разрешенных приложений из политики EventViewer:

<Allow ID="ID_ALLOW_A_6" FriendlyName="GLOBALROOT\Device\HarddiskVolume4\Program Files\7-Zip\7zFM.exe FileRule" MinimumFileVersion="0.0.0.0" FilePath="GLOBALROOT\Device\HarddiskVolume4\Program Files\7-Zip\7zFM.exe" />
 <Allow ID="ID_ALLOW_A_14" FriendlyName="GLOBALROOT\Device\HarddiskVolume4\Program Files\7-Zip\7-zip.dll FileRule" MinimumFileVersion="0.0.0.0" FilePath="GLOBALROOT\Device\HarddiskVolume4\Program Files\7-Zip\7-zip.dll" />
<Allow ID="ID_ALLOW_A_11" FriendlyName="GLOBALROOT\Device\HarddiskVolume4\Program Files\Mullvad VPN\resources\mullvad-daemon.exe FileRule" MinimumFileVersion="0.0.0.0" FilePath="GLOBALROOT\Device\HarddiskVolume4\Program Files\Mullvad VPN\resources\mullvad-daemon.exe" />

после создания этой политики, я объединил ее с политикой, которую я создал ранее, основанной на Microsoft ISG (Signed and reputable mode), и в итоговой политике, в результате слияния, это правила политики, которые я установил:

<Rules>
<Rule>
  <Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
  <Option>Enabled:UMCI</Option>
</Rule>
<Rule>
  <Option>Enabled:Inherit Default Policy</Option>
</Rule>
<Rule>
  <Option>Enabled:Update Policy No Reboot</Option>
</Rule>
<Rule>
  <Option>Enabled:Intelligent Security Graph Authorization</Option>
</Rule>
<Rule>
  <Option>Enabled:Developer Mode Dynamic Code Trust</Option>
</Rule>
<Rule>
  <Option>Enabled:Revoked Expired As Unsigned</Option>
</Rule>
<Rule>
  <Option>Required:Enforce Store Applications</Option>
</Rule>
<Rule>
  <Option>Required:WHQL</Option>
</Rule>
<Rule>
  <Option>Enabled:Dynamic Code Security</Option>
</Rule>
<Rule>
  <Option>Disabled:Runtime FilePath Rule Protection</Option>
</Rule>
<Rule>
  <Option>Enabled:Invalidate EAs on Reboot</Option>
</Rule>
<Rule>
  <Option>Enabled:Allow Supplemental Policies</Option>
</Rule>
<Rule>
  <Option>Enabled:Advanced Boot Options Menu</Option>
</Rule>
<Rule>
  <Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>

Сначала я подумал, что программы, работающие под учетной записью SYSTEM, являются драйверами в режиме ядра. Прочитав комментарий и ответ ниже, я понял, что это не так. Меня заставило так думать то, что 1)

в здесь: рядом с “FilePath”

говорится: “Правила FilePath применяются только к двоичным файлам в режиме пользователя и не могут быть использованы для разрешения драйверов в режиме ядра.”

и 2)

Когда я использовал это, чтобы создать разрешающий список политики WDAC на основе журналов Event Viewer, только программа, работающая как SYSTEM, не смогла выполняться, а другие программы, такие как 7-zip, смогли.

New-CIPolicy -FilePath .\EventsPolicy.xml -Audit -Level FileName -Fallback FilePath –UserPEs -UserWriteablePaths -MultiplePolicyFormat 3> .\EventsPolicyWarnings.txt 

Политика WDAC, созданная с использованием этого, разрешила всем программам, которые были бы заблокированы WDAC, выполняться:

New-CIPolicy -FilePath .\EventsPolicy.xml -Audit -Level hash –UserPEs -UserWriteablePaths -MultiplePolicyFormat 3> .\EventsPolicyWarnings.txt 

Нет, процессы, работающие как SYSTEM, не работают в режиме ядра. Краткое объяснение:

Все драйверы работают в едином процессе ядра вместе с остальной частью ядра.

Процесс id 0 — это “процесс ожидания”, а процесс id 4 (в XP и позже) — “процесс” ядра.

из этого ответа

Например, вот процесс ядра, под которым работают все драйверы в режиме ядра (PID 4):

Я не уверен, не видя вашего правила FilePath или как вы его создали, но есть множество причин, по которым это может не работать:

• должно быть сгенерировано уникальное, полностью квалифицированное правило пути для каждого файла в сканируемом пути, если не использовать подстановочный знак *
• Подстановочные знаки можно использовать только в начале или в конце правила FilePath (не посредине). Только один подстановочный знак разрешен на одно правило пути.
• Если filepath позволяет права записи для любого SID не в списке администраторов WDAC, filepath считается пользовательски записываемым. WDAC не пропустит правило, если специально не отключить Runtime FilePath Rule Protection
• Правила хэширования позволяют вносить лёгкие изменения, поскольку хэш файла не изменяется при переименовании, пересертификации, обновлении временной метки и т.д.
• В настоящее время существует ошибка, из-за которой MSIs не могут быть разрешены в правилах пути файла.

РЕДАКТИРОВАНИЕ: Я лично не использую пути к файлам типа \Device\HarddiskVolume4\, так как номер тома не гарантирован. Попробуйте использовать -ScanPath для генерации действительных правил пути к файлам:

New-CIPolicy -ScanPath 'C:\Program Files\7-Zip' -UserPEs -FilePath .\FilePolicy.xml -Level FilePath

Вероятно, вам не стоит использовать уровень FilePath, и вот почему. Во-первых, он не поддерживает файлы в режиме ядра, поэтому только файлы в режиме пользователя могут быть разрешены или запрещены через уровень FilePath.

Во-вторых, это небезопасно, особенно если путь доступен для записи неадминистраторам. Они полностью подрывают цель политик WDAC (Управление Приложениями).

А причина, по которой пути к файлам, указанные в журналах событий, могут быть не пригодны напрямую для авторизации программы, заключается в том, что они могут указывать на временные файлы в директории TEMP, которые создаются во время установки программы и удаляются после, или они могут быть не в правильном формате, таком как C:\, и вместо этого имеют другие префиксы, такие как \Device\Harddiskvolume3.

После использования командлетов ConfigCI, указанных в вашем вопросе, я понял, что создание приложения с графическим интерфейсом принесет пользу мне и другим, кто хочет использовать WDAC (Управление Приложениями), поэтому я создал AppControl Manager, это открытый код, бесплатный и вы можете посмотреть его здесь:

https://github.com/HotCakeX/Harden-Windows-Security/wiki/AppControl-Manager

Я написал статью, в которой использовал приложение для генерации журналов аудита и создания политик с их помощью, что именно то, что вы пытались сделать:

https://github.com/HotCakeX/Harden-Windows-Security/wiki/How-To-Generate-Audit-Logs-via-App-Control-Policies

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