Enforced Uninstall Linux

What the Linux application remover does

This Automox Worklet™ removes a named application from Linux endpoints by reading the distribution name from /etc/os-release and running the matching uninstall command. The package name is supplied through the APP_NAME variable, which an administrator sets inside the evaluation and remediation scripts before saving the Worklet.

The Worklet handles four distribution families. On Ubuntu endpoints it runs dpkg --remove. On Fedora it runs dnf remove. On Alpine it runs apk del. On Gentoo it runs emerge --deselect. Any other DISTRO value causes the script to log Unsupported OS/Distro and skip the endpoint, so RHEL, CentOS, Debian, Rocky, Alma, and similar distributions are not in scope for this Worklet.

The evaluation script returns a non-compliant exit code whenever the distribution is one of the four supported families, which triggers the remediation phase. The remediation script then issues the distribution-specific uninstall command and prints Uninstalling $APP_NAME and Uninstall of $APP_NAME Complete to the Automox activity log.

Why enforce an unauthorized-software baseline

Unauthorized packages are the slow leak in most Linux fleets. A developer apt-installs a TeamViewer or AnyDesk client to debug a vendor issue, an SRE sideloads an unapproved monitoring agent, an end-of-life version of Java or Python lingers on a long-running server because no one wrote the removal ticket. Each one is an extra service to patch, an extra binary an EDR has to learn, and an extra finding waiting for the next CIS or PCI-DSS audit.

CIS Linux Benchmark controls in section 2 call out specific legacy packages that must not be present on hardened endpoints, including telnet, rsh, talk, and ldap clients. This Worklet gives you a way to turn that policy statement into a recurring enforcement job: name the package, target the policy at your Linux groups, and let Automox re-check on the next evaluation cycle if the package returns.

How unauthorized-package removal works

1. Evaluation phase: The script reads the NAME field from /etc/os-release and branches on the value. For Ubuntu it builds a dpkg -l | grep -i $APP_NAME check, for Fedora a dnf list installed | grep -i $APP_NAME check, for Alpine an apk -e info | grep -i $APP_NAME check, and for Gentoo an equery list | grep -i $APP_NAME check. If the distribution matches one of the four supported families, the script exits non-zero so Automox schedules remediation. If the distribution is unrecognized, the script logs Unsupported OS/Distro and stops.

2. Remediation phase: The script re-detects the distribution and runs the matching uninstall command. Ubuntu endpoints run dpkg --remove $APP_NAME, Fedora endpoints run dnf remove $APP_NAME, Alpine endpoints run apk del $APP_NAME, and Gentoo endpoints run emerge --deselect $APP_NAME. The script echoes Uninstalling $APP_NAME before the command and Uninstall of $APP_NAME Complete after it, so both messages land in the Automox activity log for the run.

Linux package-removal requirements

• Linux endpoint running one of the four supported distributions: Ubuntu, Fedora, Alpine, or Gentoo. The script matches the NAME field in /etc/os-release literally against alpine, Ubuntu, gentoo, or fedora.

• Root or sudo privileges for the Automox agent so dpkg, dnf, apk, and emerge can complete uninstall operations.

• Edit both evaluation.sh and remediation.sh and set APP_NAME to the exact package name as the local package manager records it (for example, teamviewer not TeamViewer, openjdk-11-jre not openjdk). The APP_NAME variable ships empty and must be populated before the Worklet does anything useful.

• The package must have been installed through the distribution's native package manager. Self-extracting .run installers, /opt-mounted vendor packages, snaps, and flatpaks are out of scope and need a separate Worklet.

• For packages with running services (Java application servers, monitoring agents, remote-access tools), pair this Worklet with a service-stop Worklet on a higher-priority policy so the daemon is halted before removal.

• Schedule the policy on a recurring cadence (daily or weekly) so reinstall attempts surface on the next evaluation cycle, not on the next audit.

Expected state after application removal

After a successful remediation run, the matching package query returns no result for APP_NAME. On Ubuntu, dpkg -l $APP_NAME no longer lists an installed status. On Fedora, dnf list installed $APP_NAME reports no matching packages. On Alpine, apk -e info $APP_NAME exits non-zero. On Gentoo, the package is removed from the world file by emerge --deselect and is no longer pulled in by future dependency resolution.

Validate the removal by re-running the distribution's installed-package query and by checking that any associated service is no longer listed in systemctl list-unit-files. For audit evidence, capture the Automox activity log entry, the exit code, and the Uninstalling / Uninstall Complete echo lines, then store them with the policy run identifier. If an administrator or build script reinstalls the package later, the next evaluation flags the endpoint and the Worklet removes it again.