4.1 Packages: Anatomy, Command Syntax, Parameters and File Distribution

4.1 Packages: Anatomy, Command Syntax, Parameters and File Distribution

Quick Summary: In Tanium, Sensors read endpoint state, while Packages change endpoint state. A Package is a reusable blueprint containing command-line execution instructions, optional payload file attachments, dynamic parameter definitions, execution timeout limits, and an optional verification sensor. When deployed as an Action, the Tanium Client downloads any required files via peer-to-peer linear chains, validates cryptographic signatures against tanium.pub, and executes the command under privileged accounts (LocalSystem on Windows, root on Linux/macOS). Mastering package anatomy, variable substitution syntax ($1, $2), timeout safeguards, and verification sensors is fundamental to operational remediation and to blueprint objective TA-1, given a scenario, make changes to an endpoint.

---

1. Sensors vs. Packages: The Operational Divide

Understanding the fundamental architectural boundary between Sensors and Packages is the most critical core concept in the Tanium platform:

+---------------------------------------------------------------------------------------------------+
|                                 SENSORS VS. PACKAGES IN TANIUM                                    |
+---------------------------------------------------------------------------------------------------+
|  DIMENSION               | SENSORS (Telemetry & Inspection)      | PACKAGES (Remediation & Change)|
+--------------------------+---------------------------------------+--------------------------------+
|  Primary Purpose         | Read-only state collection            | State modification / execution |
|  Execution Mechanism     | On-demand query in RAM                | Deployed Action on endpoint    |
|  Disk Persistence        | None (stdout buffered in memory)      | File staging + persistent state|
|  Security Governance     | Strictly non-destructive              | Governed by Action Approvals   |
|  Execution Trigger       | Asking Questions in Interact / TDS    | Action Deployment / Scheduling |
|  Targeting Model         | Question asking filter                | Target Groups / Action Groups  |
|  Verification Mechanism  | Output parsing in Results Grid        | Verification Sensor validation |
+---------------------------------------------------------------------------------------------------+

Core Philosophy: Read First, Remediate Second

Tanium enforces a closed-loop operational workflow: Ask a Question (Sensor) -> Identify Non-Compliant Systems -> Deploy a Remediation (Package) -> Ask the Question Again (Verification Sensor). While sensors must remain strictly non-destructive and side-effect free, packages are explicitly engineered to alter the local system environment—installing software updates, modifying registry configurations, restarting daemons, isolating compromised endpoints from the network, or deleting malicious artifacts.

---

2. Anatomy of a Tanium Package

A Tanium Package definition is a structured configuration object stored in the Tanium Console that specifies exactly how an endpoint must execute an operational task. Every package consists of several foundational components:

+---------------------------------------------------------------------------------------------------+
|                                     ANATOMY OF A TANIUM PACKAGE                                   |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  1. Metadata & Identification                                                                     |
|     ├── Package Name        : Unique identifier (e.g., "Install CrowdStrike Falcon Sensor")      |
|     ├── Display Name        : Human-readable label in Console                                     |
|     ├── Description         : Operational purpose, prerequisites, and instructions               |
|     └── Content Set         : RBAC scoping container (e.g., "Endpoint Management", "Custom")       |
|                                                                                                   |
|  2. Execution Configuration                                                                        |
|     ├── Command Line        : Executable string (e.g., cmd.exe /c install.cmd "$1" "$2")          |
|     ├── Source OS / Platform: Target platform filter (Windows, Linux, macOS, Solaris, AIX)       |
|     └── Command Timeout     : Maximum runtime allowed before forced termination (default: 15 min)|
|                                                                                                   |
|  3. Payload & File Attachments                                                                    |
|     ├── Local Uploads       : Binaries, scripts, or archives stored directly on Tanium Server     |
|     ├── Remote URLs (HTTP)  : External file URLs downloaded and cached by Tanium Server          |
|     └── Hash & Signature    : SHA-256 integrity hash + private key digital signature             |
|                                                                                                   |
|  4. Dynamic Parameters & Verification                                                             |
|     ├── Parameter Definitions: User input forms (text fields, dropdowns, checkboxes, credentials) |
|     └── Verification Sensor : Sensor evaluated post-execution to confirm operational success      |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

Component Breakdown

1. Package Name and Content Set:
   • The package is assigned to a specific Content Set, which determines which user roles and personas have permissions to view, edit, or deploy the package.
2. Command Line:
   • The exact shell command or binary execution string passed to the operating system command interpreter. The command line must handle paths, flags, silent install switches, and parameter variables.
3. Source Files (File Attachments / Payloads):
   • Packages can contain zero, one, or multiple file attachments. Examples include .msi installers, .exe setups, .ps1 or .sh script files, .zip archives, or configuration templates.
   • If a package requires no external files (for example, running native shell commands like net stop Spooler or systemctl restart sshd), it is created as a fileless package.
4. Command Timeout (Timeout Seconds):
   • Defines the maximum duration the Tanium Client will allow the command subprocess tree to run. The value is configured on the package, so it is set to suit the work: a service restart needs seconds, a large database upgrade may need hours. Treat the behaviour as the exam-relevant fact rather than memorising a default.
   • If the process exceeds this threshold, the Tanium Client forcibly kills the process tree (via TerminateProcess on Windows or SIGKILL on POSIX) and logs an execution timeout failure.
5. Verification Sensor:
   • An optional but highly recommended configuration that links a specific sensor to the package. After the action executes, Tanium automatically evaluates the verification sensor to determine if the desired outcome was achieved (e.g., checking if Running Service[Spooler] returns Stopped).

---

3. Package Command Line Syntax & Variable Substitution

The command line field tells the local Tanium Client how to invoke the payload or native OS commands. Because the Tanium Client runs as a non-interactive background service, all commands must execute silently and without user interaction.

Platform-Specific Command Execution Syntax

Variable Substitution Tokens ($1, $2, $3...)

When a package uses dynamic parameters, the runtime values supplied by the deploying operator are injected into positional tokens in the command line:

• $1 represents the first parameter value.
• $2 represents the second parameter value.
• $3 represents the third parameter value (and so forth up to $N).

+---------------------------------------------------------------------------------------------------+
|                               VARIABLE SUBSTITUTION IN ACTION                                     |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  Package Parameter Definition:                                                                    |
|  * Parameter 1 (Text Box)  : Service Name       -> User enters: "WSearch"                         |
|  * Parameter 2 (Dropdown)  : Startup Type       -> User selects: "Disabled"                       |
|                                                                                                   |
|  Configured Command Line:                                                                         |
|  `powershell.exe -ExecutionPolicy Bypass -File Set-ServiceConfig.ps1 -Name "$1" -StartupType "$2"`|
|                                                                                                   |
|  Evaluated Command Line Executed on Endpoint:                                                     |
|  `powershell.exe -ExecutionPolicy Bypass -File Set-ServiceConfig.ps1 -Name "WSearch" -StartupType "Disabled"`
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

[!IMPORTANT] Quotes Around Variable Tokens: Always enclose parameter variables in double quotes ("$1", "$2") within the command line definition. If an operator enters a parameter string containing spaces (such as a file path C:\Program Files\Application\ or a service display name Print Spooler), omitting quotes will cause the shell interpreter to split the string into separate arguments, breaking script execution.

4. File Attachments, Payloads & Linear Chain Distribution

Deploying software packages across 100,000+ distributed endpoints in traditional client-server architectures creates severe network bottlenecks (WAN saturation) and overwhelms centralized distribution servers. Tanium solves this through its patented Linear Chain Peer-to-Peer Distribution Architecture.

+---------------------------------------------------------------------------------------------------+
|                                 PAYLOAD DISTRIBUTION MECHANICS                                    |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  1. Ingestion & Hashing                                                                           |
|     * Admin uploads payload (e.g., `setup.exe`, 500 MB) to Tanium Server.                         |
|     * Tanium Server calculates SHA-256 hash and generates a signed file manifest.                 |
|                                                                                                   |
|  2. Chunking & Caching                                                                            |
|     * Payload is divided into binary chunks.                                                |
|     * Only the backward leader of each linear chain downloads chunks from the    |
|       Tanium Server / Module Server or Zone Server.                                               |
|                                                                                                   |
|  3. Peer-to-Peer Relaying                                                                         |
|     * The Leader relays chunks to its downstream peer over TCP Port 17472.                        |
|     * Each client verifies chunk hashes in transit and caches them in its local `Downloads` dir.  |
|     * Result: WAN link to branch office receives exactly 1 copy of the 500 MB file, regardless    |
|       of whether there are 10 or 10,000 endpoints in that subnet!                                 |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

File Attachment Sources

• Local File Uploads: Uploaded directly from the administrator's local machine through the Tanium Console and stored in the Tanium Server database / content directory.
• Remote URLs (HTTP/HTTPS Downloads): The package references an external URL (e.g., an internal corporate repository https://repo.corp.internal/pkgs/patch.tar.gz). The Tanium Server connects to the remote URL, downloads the file, generates the cryptographic manifest, and distributes it down the linear chains.

Client-Side File Staging

When an action requires file attachments:

1. The Tanium Client streams and assembles the chunks into the Tanium Client/Downloads/Action_<ActionID> directory.
2. The client verifies the assembled file's SHA-256 hash against the signed package manifest.
3. The client executes the command line within that working directory.
4. Upon action completion (or expiration), the Tanium Client automatically purges temporary staging directories according to client cleanup retention policies to prevent disk exhaustion.

---

5. Package Parameters & Dynamic User Inputs

Hardcoding dynamic attributes (such as server IP addresses, license keys, target directory paths, or account usernames) into static package definitions creates administrative sprawl and maintenance overhead. Tanium provides a rich Package Parameters UI Schema that allows package authors to define input forms presented to operators when deploying an action.

+---------------------------------------------------------------------------------------------------+
|                                 PACKAGE PARAMETER INPUT TYPES                                     |
+---------------------------------------------------------------------------------------------------+
|  PARAMETER TYPE          | UI CONTROL RENDERED IN CONSOLE        | OPERATIONAL USE CASE           |
+--------------------------+---------------------------------------+--------------------------------+
|  Text String             | Single-line text input field          | Hostnames, paths, user IDs     |
|  Numeric / Integer       | Number spinner with min/max bounds    | Port numbers, retry limits     |
|  Dropdown Selection      | Single-choice select menu             | Action modes (Install/Remove)  |
|  Checkbox (Boolean)      | Toggle checkbox (returns true/false)  | Force reboot flag, debug flag  |
|  Password / Credential   | Masked text input field               | Service account passwords      |
|  Multi-line Text Area    | Expandable text box                   | Custom configuration blocks    |
+---------------------------------------------------------------------------------------------------+

Parameter Validation Rules

Package authors can enforce validation rules on parameters to prevent operator error before deployment:

• Required vs. Optional: Flagging a parameter as mandatory prevents action deployment until a valid value is provided.
• Regular Expression (Regex) Validation: Enforces specific string formats (e.g., validating that an input matches an IPv4 address pattern ^\d{1,3}(\.\d{1,3}){3}$ or email format).
• Default Values: Pre-populates fields with recommended operational defaults (e.g., Default Port: 8080, Default Mode: Audit).

---

6. Verification Sensors & Closed-Loop Validation

A critical differentiator of Tanium compared to legacy systems management tools is native Closed-Loop Verification. In traditional tools, a package is considered "successful" if the operating system process returns an exit code of 0, even if the installer crashed silently or failed to start the underlying service.

+---------------------------------------------------------------------------------------------------+
|                             CLOSED-LOOP VERIFICATION ARCHITECTURE                                 |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  1. Initial Query (Identify Non-Compliance)                                                       |
|     Get Service State[Spooler] from all machines with Is Windows = True                           |
|     -> Result: 450 endpoints return "Running"                                                     |
|                                                                                                   |
|  2. Remediation Deployment                                                                        |
|     Deploy Action: "Stop and Disable Print Spooler"                                               |
|     Verification Sensor Configured: `Service State[Spooler]`                                      |
|     Expected Verification State   : `Stopped` or `Disabled`                                       |
|                                                                                                   |
|  3. Automated Post-Execution Evaluation                                                           |
|     * Client executes `sc.exe stop Spooler && sc.exe config Spooler start=disabled`               |
|     * Client automatically executes the Verification Sensor in RAM.                               |
|     * If sensor output == "Stopped", action status is marked as VERIFIED SUCCESS.                 |
|     * If sensor output != "Stopped", action status is flagged as VERIFICATION FAILED.              |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

Verification Sensor Benefits

• Immediate Confirmation: Eliminates the need for operators to manually construct and run follow-up queries after every deployment.
• True State Validation: Protects against "false positives" where a batch script exits with code 0 despite failing to perform the intended configuration change.
• Audit Compliance: Provides verifiable cryptographic proof that endpoints reached the compliant desired state.

---

7. Standard Built-In vs. Custom Packages

---

8. Common Authoring Pitfalls & Exam Traps

+---------------------------------------------------------------------------------------------------+
|                              PACKAGE AUTHORING PITFALLS & SOLUTIONS                               |
+---------------------------------------------------------------------------------------------------+
|  PITFALL 1: Unquoted Variable Tokens with Spaces                                                  |
|  * Error  : `cmd.exe /c install.bat $1` when $1 = `C:\Program Files\App`                          |
|  * Result : Batch script receives multiple arguments: arg1=`C:\Program`, arg2=`Files\App`.        |
|  * Fix    : Always use double quotes: `cmd.exe /c install.bat "$1"`.                               |
|                                                                                                   |
|  PITFALL 2: Interactive UI Prompts Causing Timeouts                                                |
|  * Error  : Executing `msiexec.exe /i setup.msi` without `/qn` or `/quiet`.                       |
|  * Result : Installer opens an invisible GUI dialog in Session 0 (SYSTEM). Nobody can click Next. |
|             The command hangs until the 15-minute Command Timeout terminates the process.         |
|  * Fix    : Always verify silent/unattended flags (`/quiet`, `/qn`, `/norestart`, `-s`).          |
|                                                                                                   |
|  PITFALL 3: Missing PowerShell ExecutionPolicy Flags                                              |
|  * Error  : Calling `powershell.exe -File script.ps1`.                                            |
|  * Result : Fails if endpoint PowerShell execution policy is set to `Restricted` or `AllSigned`.   |
|  * Fix    : Explicitly specify `-ExecutionPolicy Bypass -NoProfile -NonInteractive`.              |
|                                                                                                   |
|  PITFALL 4: Modifying Default Built-in Packages Directly                                          |
|  * Error  : Attempting to edit a default package shipped in Tanium Core Content.                  |
|  * Result : Console rejects edit or changes will be overwritten during the next content update.   |
|  * Fix    : Clone the built-in package, rename it with a custom prefix, and save to a custom set. |
+---------------------------------------------------------------------------------------------------+

---

9. Details Tanium documents that operators rely on

Where package files land on the endpoint

When you deploy an action, Tanium Clients download the associated package files and distribute them among peers in the client linear chains. Each client stores the package files for an action in:

<Tanium Client installation directory>/Downloads/Action_<ID>

where <ID> is the action identifier. This matters twice over: it is where you look when diagnosing a failed deployment on an endpoint, and it is why the client's download cache has a configurable size cap rather than growing without limit.

The action ID is also how you navigate client logs. On managed endpoints the Tanium Client records action IDs in its log files, so an action ID taken from the console is the key that unlocks the endpoint-side story of what happened.

How parameter values reach the script safely

Package parameters follow the same encode-and-decode pattern as sensor parameters. When you deploy an action with a parameterized package, the Tanium Server encodes the parameter values before passing them to the package script, and includes the encoded values in a temporary package deployed in the action. When clients start the action, they run the package script, which applies UTF-8 decoding to the encoded values.

The practical consequence is the same as for sensors: type the value as it really is — a path with spaces, a name with an apostrophe — and let the platform handle transport encoding.

Sensor-sourced packages

A sensor-sourced package takes its parameter value from sensor output that you select in the Question Results grid, rather than from a form you fill in. The workflow is: ask a question, select the result rows, and deploy an action with the sensor-sourced package. The list of available packages includes sensor-sourced packages only if your selections in Question Results actually have a value to pass to the package.

Two constraints from Tanium's documentation are worth knowing:

• If you select results with multiple output values for a sensor, the Tanium Server creates a separate action for each value. Because you can select a maximum of 100 results for one action deployment, a package whose name includes a sensor produces a maximum of 100 actions.
• A sensor name containing an underscore causes errors and unexpected results in sensor-sourced packages.

Packages and content sets

A package belongs to a content set, and that content set is what roles grant permission against — including the permissions covered in section 4.2, where Approve Action and Bypass Action Approval are granted per content set. A package sitting in the wrong content set is the usual reason an operator can see a package but cannot deploy it, or can deploy it without the approval the organisation intended.

Verification is not optional in practice

The verification sensor closes the loop from "the command exited 0" to "the endpoint is actually in the state I wanted". Exit code 0 means the process finished without reporting an error; it does not mean the service is running, the file is gone, or the setting took effect. Section 4.3 covers the full verification workflow, which is blueprint objective TA-2.