Forum Discussion
Solved
WDAC allow rule not working for non program or windows directories
I was testing WDAC. I used App Control Wizard to create a Multiple Policy Format Base Policy. I selected the Default Windows Mode and left all option as default (except I turned off audit mode as I was just testing it in a testing machine). Set up the allow rules for the following paths
- %WINDIR%\*
- %OSDRIVE%\Program Files\*
- %OSDRIVE%\Program Files (x86)\*
- %OSDRIVE%\ProgramData\*
- %OSDRIVE%\Users\*
- %OSDRIVE%\Temp\*
Use the Citool to update the policy to a test machine. The WDAC worked for the first 4 directories. I can run MSOffice and programs that are located in these 4 directories and their subdirectories.
However, it did not work for the last 2 directories (c:\Users and c:\Temp). I used the same program that worked in the first 4 directories. The program execution was blocked by WDAC in c:\Temp. It could be run in c:\Users but not in its subdirectories.
I thought WDAC did not perform blocking by default for the first 4 directory. I removed the allow rules. As soon as I removed the allow rules and update the policy using Citool. It did block program running from the 4 directories.
I looked at the event log and cannot figure why the behavior is different from the first 4 directories and the last 2.
Appreciate any comment.
Thanks
I looked the WDAC rule. I think I found the reason. I need to disable Runtime FilePath Rule Protection (default is enable) in order to allow FilePath rules for paths that are only writable by an administrator. It explains the reason why it works for c:\users but not its subdirectories. As soon as I disable Runtime FilePath Rule Protection, it worked perfectly.
Thanks
Hi James, have you come across a lot of DLLs files are getting blocked? especially when deploying windows
updates? Cheers
Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files (x86)\ManageEngine\UEMS_Agent\patches\112079-SQLServer2022-KB5048038-x64.exe) attempted to load \Device\HarddiskVolume3\ffba7c85dc0bb82b1e8ccd77a6f6aeaa\SETUP.EXE that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{dfdf74bc5-c0e7-4e17-af3b-903f49b7df0c}).
I did have some DLLs files blocked in \Device\HarddiskVolume3\Windows\System32, but nothing gets blocked in \Device\HarddiskVolume3\Program Files (x86). At this moment, I just turn on WDAC in my machines for testing. Haven't roll out for wider group testing. Also, the blocking seems not impact anything in my machines.
Could it be you need to whitelist \Device\HarddiskVolume3\Program Files (x86)\ in addition to %OSDRIVE%\Program Files (x86)\*?
I looked the WDAC rule. I think I found the reason. I need to disable Runtime FilePath Rule Protection (default is enable) in order to allow FilePath rules for paths that are only writable by an administrator. It explains the reason why it works for c:\users but not its subdirectories. As soon as I disable Runtime FilePath Rule Protection, it worked perfectly.
Thanks
The issue may stem from the way WDAC applies rules to different directory types, particularly system folders like "Users" and "Temp," which can have additional security or permission settings that prevent applications from running as expected. WDAC can sometimes require more specific rules for these directories, as they might involve user-specific or system-level restrictions that differ from standard program directories. I recommend reviewing the rule definitions and ensuring that the correct permissions are applied, particularly for user directories (e.g., c:\Users) and temporary directories (e.g., c:\Temp). You might need to create more granular rules or include additional exceptions for these folders. Additionally, double-check if there are any other conflicting group policies or restrictions that could interfere with WDAC's behavior in these directories.
