Allow custom SID for writable directories #6
Conversation
|
|
…d "RuleCollection" properties
Use hashtable output in GetSafePathsToAllow.ps1 supporting "Label" an…
| @@ -157,13 +157,23 @@ foreach($fsp in $FileSystemPaths) | |||
| # Get-AppLockerFileInformation -Directory inspects files with these extensions: | |||
| # .com, .exe, .dll, .ocx, .msi, .msp, .mst, .bat, .cmd, .js, .ps1, .vbs, .appx | |||
| # But this script drops .msi, .msp, .mst, and .appx | |||
| [array]$scanFileTypes = @('*.bat','*.com','*.exe','*.dll','*.ocx','*.js','*.ps1','*.pyd','*.vbs','*.xll') | |||
There was a problem hiding this comment.
I wish we could specify arbitrary file extensions, but the PowerShell cmdlets don't support them. The problem is that when you pass the Get-AppLockerFileInformation results to New-AppLockerPolicy, it relies on file extension to determine file type based on its own hardcoded list. If you try to manipulate the path name in the file information object to give it a standard extension before passing it to New-AppLockerPolicy, it will still fail because it goes to look for that file and doesn't find it. I considered and quickly discarded an idea to create hard links to the new names and then deleting them after building. For now I'm just running Scan-Directories.ps1 and pulling data out of there for HashRuleData.ps1, or just insisting on good publisher/productname data.
Changes below using CustomUserOrGroupSid variable defined in UnsafePathsToBuildRulesFor.ps1 to allow specify custom SID instead of Everyone's
User case is for allowing specific users' Group executing files from writable directory. Changes allow automating rules creation process instead of manually reviewing/changing them