Reply to thread

Message

<blockquote data-quote="Andy Ful" data-source="post: 957064" data-attributes="member: 32260">I updated the post. Renaming the shortcut worked for me (I tested it after installing 8GadgetPack / Sidebar on my testing computer). We are in email contact with Krusty. After renaming the shortcut the Sidebar thinks that it does not have to start with Windows, but the renamed shortcut starts it anyway.The Sidebar issue showed the limitation of the combined Disalowed/Unrestricted rules with wildcards.In the H_C Recommended settings the SRP makes several actions for files in the user Startup folder :<ol>
<li data-xf-list-type="ol">Disallowed Default Security Level (blocks files by default).</li>
<li data-xf-list-type="ol">Unrestricted rules for EXE and MSI files in user AppData subfolders.</li>
<li data-xf-list-type="ol">Disallowed rule for files (blocks also EXE and MSI) in the user Startup folder (it is a subfolder of AppData).</li>
<li data-xf-list-type="ol">Unresctricted rule for a shortcut file.</li>
</ol>All four SRP actions are done at the same time for files located in the startup folder. The two last rules work differently for paths with wildcards. Without wildcards the last take precedence over the second last. For paths with wildcards in the filename, the opposite is true.Edit.The rule from point 3 is unnecessarily restrictive it should block only EXE and MSI files instead of all files - other files are already blocked by point 1. I could solve the issue by making it less restrictive. This would require removing 20 rules and adding 40 new rules. There is also a possibility to extend whitelisting by hash to include shortcuts - this would be probably the best solution for shortcuts with randomly changing file names in the user Startup folder.</blockquote>

[QUOTE="Andy Ful, post: 957064, member: 32260"] I updated the post. Renaming the shortcut worked for me (I tested it after installing 8GadgetPack / Sidebar on my testing computer). We are in email contact with Krusty. After renaming the shortcut the Sidebar thinks that it does not have to start with Windows, but the renamed shortcut starts it anyway. The Sidebar issue showed the limitation of the combined Disalowed/Unrestricted rules with wildcards. In the H_C Recommended settings the SRP makes several actions for files in the user Startup folder : [LIST=1] [*]Disallowed Default Security Level (blocks files by default). [*]Unrestricted rules for EXE and MSI files in user AppData subfolders. [*]Disallowed rule for files (blocks also EXE and MSI) in the user Startup folder (it is a subfolder of AppData). [*]Unresctricted rule for a shortcut file. [/LIST] All four SRP actions are done at the same time for files located in the startup folder. The two last rules work differently for paths with wildcards. Without wildcards the last take precedence over the second last. For paths with wildcards in the filename, the opposite is true. Edit. The rule from point 3 is unnecessarily restrictive it should block only EXE and MSI files instead of all files - other files are already blocked by point 1. I could solve the issue by making it less restrictive. This would require removing 20 rules and adding 40 new rules. There is also a possibility to extend whitelisting by hash to include shortcuts - this would be probably the best solution for shortcuts with randomly changing file names in the user Startup folder. [/QUOTE]

Verification