Given the constant risk associated with browser extensions, I sought to create policies for a block list/allow list rule to block everything except items on the allow list. However, I wanted to avoid stopping and re-issuing the policy every time an update was necessary. Therefore, I devised the following method and would like to know if there’s interest in a detailed write-up of this approach.
Some may argue that having a singular policy for each browser could be more effective. My goal though was to reduce the overhead involved in updating relevance, ActionScript, and stopping and re-issuing the policy whenever an update to the allow list was made.
Here is a high-level overview of the workflow:
- Manual Task: This task updates the allow list for each browser and sends the information to the root server (or any other designated server capable of executing a REST API command). The task includes the name of the extension and the extension store ID in plain text.
- Policy Action 1: This action monitors a folder for allow list updates on the reference server. When the allow list is updated, the policy action reads each line, encodes the plain text entries line-by-line with Base64, writes them to a separate file (e.g., filename.dat), and uploads it to the appropriate site via REST API (using Curl or an alternative method). The dat file is small and is propagated to any clients that are members of the targeted site.
- Policy Action 2: This action reviews the block list policy registry value and reinforces the block list for Edge, Chrome, and Firefox if there are any changes to that value.
- Policy Action 3: This action monitors the dat file in the client site. If the decoded values in the dat file do not match the policy values in the registry key for the allow list for Edge, Chrome, and Firefox, the policy will delete the current allow list and re-issue it to align with the current allow list.
