The Linux Application Block Policy helps admins prevent specific applications from running on managed Linux devices enrolled in Swif. It’s commonly used for:
Security hardening (blocking risky tools or unapproved software)
Compliance enforcement (ensuring only approved applications are used)
Productivity controls (restricting distracting apps)
Reducing attack surface (limiting execution of interpreters or remote-access tools)
This policy can be applied to both BYOD and company-owned Linux devices.
What this policy does
When this policy is applied, Swif monitors process execution on the device.
If an application matches an entry in the Disallowed Application List:
It will be blocked from launching
If it’s already running, it will be terminated automatically
A prevention event is generated in device logs (and in the AI Security Report, if enabled)
This enables application-level enforcement without requiring you to modify OS security frameworks.
Requirements
A Linux device enrolled in Swif
Works across major Linux distributions (for example: Ubuntu, Debian, Fedora, CentOS, Rocky Linux, and others)
Configuration options
1) Disallowed Application List (appNames)
What it is: A list of application/executable names to block.
How it works:
Each entry must match the process/executable name the system runs.
Swif blocks and stops any process whose name equals a disallowed entry.
Examples of disallowed names
firefoxzoomslackspotifychromium-browserpython3(blocks Python execution)gedit
2) Block Package Manager (blockPackageManager)
What it is: A toggle to restrict package manager usage for standard users.
Type: true/false
Default:
falseLimitation: Not supported on NixOS
When enabled (true):
Swif will block package manager usage from standard user permissions (behavior depends on distro/package tools).
When disabled (false):
Swif won’t apply package manager restrictions.
Note: This setting is meant to reduce installation of unapproved software. It doesn’t replace OS-level privilege controls (like sudo policies).
How blocking behaves on the device
Once enforced:
Swif continuously monitors active processes.
If a process name matches a disallowed entry:
The process is terminated immediately
A prevention event is logged
If the user tries to open the app again:
It is blocked instantly
The behavior continues until the policy is removed or updated.
Best practices (recommended)
Use exact executable/process names
Blocking relies on the name being correct. Confirm the real executable name using:
which <app>
Or inspect running processes:
ps -aux | grep <appname>
Common pitfall: an app may be launched under a different name than its brand (e.g., chrome vs google-chrome).
Start with visibility before enforcement
Before blocking, consider collecting usage signals first (where available in your environment) so you don’t break critical workflows unexpectedly. This helps you identify:
What’s actually being used
Which teams depend on certain tools
Whether there are alternate executables/child processes involved
Pilot first, then roll out
Apply to a small group first (IT or a test department), validate behavior, then expand:
Confirm the right processes are blocked
Confirm business-critical apps are not affected
Document exceptions and edge cases you discover
Avoid overly broad blocks
Blocking interpreters/tools like python3, bash, or node can be effective for high-security environments, but can also break:
Developer workflows
IT automation scripts
Legitimate internal tooling
If you need this kind of restriction, pilot carefully and coordinate with impacted teams.
Maintain an “approved software baseline”
Keep an internal list of approved apps and versions, and use this policy to block anything outside that baseline. This is especially helpful for:
Compliance audits
Repeatable device provisioning
Standardizing tooling across fleets
Pair with package manager restrictions (when appropriate)
If your goal is “users shouldn’t install new software,” enable:
Disallowed Application List to stop known unwanted apps
Block Package Manager to reduce self-service installation paths (not supported on NixOS)
Troubleshooting
App is not being blocked
Confirm the executable name matches exactly (case/spelling matters).
Check whether the app launches under a different name (example:
chromevsgoogle-chrome).Confirm the device is online and has received the latest policy.
Verify the Swif agent is up to date.
False positives or partial blocking
Some apps launch child processes with different names.
Add those child process names to the disallowed list if appropriate.
Re-check the actual running process tree after launch.
Policy doesn’t seem to take effect
Ensure the device is running the latest Swif agent version.
Try forcing a device sync (if available in your admin workflow).
Re-apply or update the policy to trigger a fresh enforcement cycle.
Summary
The Linux Application Block Policy is a lightweight and effective way to control what users can run on Linux endpoints. By configuring a Disallowed Application List (and optionally restricting package managers), you can enforce security, compliance, and productivity standards across your Linux fleet.