How to disable security warning popup about message containing script

(imported topic written by arnaud91)

Hi,

I created a task with relevance and script elements embedded in the description part of it.

When I select this task in the BES Console, a popup appears, with the title “Security Warning” saying : “This message contains script and/or relevance. Do you want to enable this dynamic content ?”, and proposing “enable” or “disable”.

Is it to possible to disable this message, ie to always enable dynamic content for all bes operators ?

I noticed that this popup doesn’t appear for tasks “Deploy” of BigFix Firewall and BigFix Antivirus sites, even if there is a script in the Description part. We would like to have the same behavior with all tasks containing dynamic content.

Regards,

Arnaud.

(imported comment written by SystemAdmin)

Hi Arnaud,

No, it is not possible to automatically accept all dynamic content for all BES Operators. You can choose to accept all content from an operator by selecting the ‘Always enable content from this source’ box though.

This current behavior was designed from a security perspective to protect you from malicious operations contained within dynamic content. Basically, dynamic content contains javascript code authored by another person which is run locally on your computer at the time you view the content and has the potential to perform harm or pull sensitive data off of your computer. The message warns you that this code is going to execute so you have the option not to run it, review the code beforehand or just let it run.

Content authored by BigFix containing dynamic content does not display the message before running because it has already been digitally signed by BigFix and verified by your BES Console. Basically, its possible BigFix could author malicious code within dynamic content in the same way as a custom author from your deployment but you have already agreed to trust code from BigFix long before your get to the point of running dynamic content. So, dynamic code authored by BigFix doesn’t represent an escalation of permission and thus you don’t need to be warned before running it. By running our code you haven’t necessarily agreed to let your custom authors run code on your computer though so we need to warn you that someone else is trying to do this and allow you to make the decision about whether you trust that author or not.

I hope this helps explain the situation, maybe there is a system we could add in in which some custom content containing dynamic features is automatically accepted but we would need to make sure that this system doesn’t allow escalation of permissions. Please post suggestions if you can think of a good way to do it!

(imported comment written by mynameisbear91)

Tyler Duni

Content authored by BigFix containing dynamic content does not display the message before running because it has already been digitally signed by BigFix and verified by your BES Console. Basically, its possible BigFix could author malicious code within dynamic content in the same way as a custom author from your deployment but you have already agreed to trust code from BigFix long before your get to the point of running dynamic content. So, dynamic code authored by BigFix doesn’t represent an escalation of permission and thus you don’t need to be warned before running it. By running our code you haven’t necessarily agreed to let your custom authors run code on your computer though so we need to warn you that someone else is trying to do this and allow you to make the decision about whether you trust that author or not.

Which PKI store does the BES console check for that? If he signs his code and has an internal CA and can distribute the certificates around into the Windows PKI store (where I work, we have an internal CA and we use Active Directory to ensure that everyone lists the CA as a root) can he use his own signed code, or does the BES client use its own crypto API?

Just wonderin’. :smiley:

(imported comment written by jeremy_spiegel91)

The Console doesn’t look in the Windows certificate store for certificates. Instead, all the certificates it needs are in the BES database.

Even though the Console checks the signature on the fixlet and is sure that it is signed by an operator in your BES deployment, we still need to let the current user decide if they trust the user that signed the fixlet. If you want to make this decision for other users (as you would by creating an AD policy to have all machines trust your root CA), you could create a BES action to set the registry key that the Console checks when it wants to know if you had checked “Always enable dynamic content from this source”. This registry key is HKCU\Software\BigFix\Enterprise Console\TrustedOperators. Create a DWORD value named for every operator and set it to a value of 1.

(imported comment written by arnaud91)

Thanks for all your answers, it really helps me !

What i will try to do is : as we are MSSP, our customers will connect to the Console through a Citrix Gateway. I will add a windows logon script for each customer windows account (used by Citrix) that creates a registry key to automatically trust Master Operator.

(imported comment written by mynameisbear91)

jeremy_spiegel

The Console doesn’t look in the Windows certificate store for certificates. Instead, all the certificates it needs are in the BES database.

Even though the Console checks the signature on the fixlet and is sure that it is signed by an operator in your BES deployment, we still need to let the current user decide if they trust the user that signed the fixlet. If you want to make this decision for other users (as you would by creating an AD policy to have all machines trust your root CA), you could create a BES action to set the registry key that the Console checks when it wants to know if you had checked “Always enable dynamic content from this source”. This registry key is HKCU\Software\BigFix\Enterprise Console\TrustedOperators. Create a DWORD value named for every operator and set it to a value of 1.

See this? This is a fine example of why I use BigFix.

(imported comment written by SystemAdmin)

Cool, thank Jeremy :slight_smile: