This chapter describes Script rules, which identify files to be tracked and managed as scripts by Carbon Black App Control. The Carbon Black App Control Server includes built-in script rules, and you can create custom rules to identify other scripts.

Carbon Black App Control tracks and manages two categories of files: executables and scripts. Executables are identified based on Carbon Black App Control’s analysis of their content. Scripts are identified by name, with the exception of certain non-Windows shell scripts.

What Carbon Black App Control Script Rules Do?

Script rules implement two types of action for files matching the rules:
Action Description
Visibility: When a file matching the script type in a rule is discovered, either because it is newly present on an agent computer or because a new rule was created, the file is added to the File Catalog and Files on Computers tables, and is tracked from that point forward. Although identified by name, a script file is hashed like other identified as “interesting” by Carbon Black App Control, and its hash is stored in the file database.
Control: When a file matching a script processor attempts to access a file identified as a script type in the same rule, that is considered a script execution. For enabled rules, script executions are controlled according to the policy settings for the computer on which the execution is attempted and any other applicable Carbon Black App Control rules.

The file state of a script identified by Carbon Black App Control depends upon when it was discovered and on the state of the setting Rescan Computers: Check to approve all existing scripts matching this definition. If the Rescan Computers box is not checked, all scripts of the type identified by the rule are treated as unapproved when executed. If the Rescan Computers box is checked, script files currently on agent-managed computers at the time of the rescan are locally approved and (unless banned by a rule) allowed to execute under all Enforcement Levels. Script files discovered after the rescan are considered Unapproved, and their execution is blocked at High or Medium Enforcement Levels.

Note: Because of the rescanning requirement described above, it is best to create and enable Script rules before you install agents on computers, whenever possible.

Script Rules and Other App Control Rules

A script file defined by a Script rule is also subject to any matching (non-script) Custom rules, including those with actions that would Ignore writes, Block, Prompt, or Report execution or writing, or Allow execution. For example, if a script file matches a Custom rule with a Write Action of Ignore, the file state of the script will be Unapproved, and execution will be blocked at High or Medium Enforcement Levels. Also, if a script file and its processor match a Custom rule with an Execute Action of Allow, the script is allowed to execute regardless of its file state.

In addition, script files can be banned or approved by hash.

There is a Rapid Config called Script Processors that allows you to limit the locations in which script processors can be run. See Rapid Configs for more details.

Shell Scripts Identified by Content

The Script rules table includes rules for native Mac and Linux shell script files, and these are enabled by default. Although scripts are generally identified by file extension and processor in an explicit rule, there is an exception for Mac and Linux shell scripts.

Some shell scripts contain special markup in their first line that identifies the default interpreter that should be used to process them. This markup is usually referred to as hashbang or shebang, and consists of the “pound” or “hash” symbol (#) followed by an exclamation point (!). For example, #!/bin/bash indicates that the /bin/bash interpreter must be used to process this script file.

Because the shebang markup clearly identifies a file as interesting to Carbon Black App Control, shell scripts with this markup are identified by content and tracked, regardless of whether there is a script rule for them. In effect, the markup creates an invisible script rule with the file as the script and the shebang markup identifying the processor.

Enforcement of rules on Mac and Linux shell scripts with the shebang pattern depends on how the script is run and whether any matching Custom Script Rule remains in effect:

  • Use the script as the command – If a script file is run as a command, it will use the processor identified in the shebang, and will be subject to the policy settings that control executables, not scripts. An example of this can be $ ./foo.sh

    Note that to run the script this way, the script itself must have execute permission in the operating system.

  • Use a defined processor/script combination as the command – If a script file is run with the processor as the command and the script file as the argument, and if this combination is defined in the shebang or a Custom Script Rule, the action will be subject to the policy settings that control scripts. An example of this can be$ csh ./foo.sh

    In this case, execution permission is not necessary for the script file.

  • Use an undefined processor/script combination – If a script file is run with the processor that is not defined in a shebang pattern for the file nor in a Custom Script Rule, the script action is not controlled by the policy settings for scripts, even if the file itself has been identified as an script to track. This includes the case in which a script file includes a shebang pattern but a different processor is used to run it.