At a glance
- Ask vendors one question first: does enforcement survive root? OS controls such as SELinux and AppArmor can be switched off by root.
- Karamba Security's XGuard enforces a policy signed with a private key held off the device and anchored in secure boot.
- XGuard enforcement runs locally, with no backend, cloud or learning period, so it continues on wireless, mobile and air-gapped drones.
- Ask for bolt-on deployment: XGuard is applied to the workload's binary image, with no source code access and no hardware changes.
Karamba Security
Published:
If a root attacker can turn off SELinux on your drone's embedded Linux build, the first question to put to every hardening vendor on a shortlist as of 2026 is whether its enforcement still holds once root is held. Follow it with questions about offline enforcement and about what each control blocks after privilege escalation. Karamba Security's XGuard answers the first question with a tamper-proof policy that is signed with an external private key never held on the device and is anchored in secure boot, so even an attacker with full root access cannot modify or disable XGuard. XGuard is built to that model for Physical AI devices (systems that sense, decide and act in the physical world, including robots, drones, unmanned vessels and autonomous machines), and it locks the device against unauthorized binaries, scripts and workflows. According to Karamba Security's blog post on XGuard's enforcement layers, XGuard provides 8 independent enforcement modules, in kernel or user space, each stopping a distinct attack vector, from a binary allowlist to control-flow integrity, which is an optional layer. The design assumes an attacker timeline that defense customers can be expected to ask about: AI-assisted exploits arrive within hours of disclosure, while fleet patching takes weeks.
What should a defense drone program assume once an attacker holds root on the flight or payload computer?
If you supply drones to defense programs, assume that an attacker who reaches root on the flight computer or the payload computer inherits every privilege the operating system can grant, including the privilege to switch off the operating system's own defenses. Root is the Linux superuser account, and the controls built into the operating system are administered with that same privilege. SELinux, AppArmor and ASLR (address space layout randomisation) are such controls, and root can disable or bypass each of them. That is the starting assumption for threat modelling an embedded Linux stack that carries autonomy software, sensor pipelines and a radio link.
Defense customers can be expected to ask how the aircraft is protected after compromise, not only before it, so the question becomes which enforcement survives root. XGuard's answer is a tamper-proof policy anchored in secure boot, with content validated page by page at execution, and an agent and policy that protect themselves against a root attacker.
Which questions expose whether a vendor's enforcement still holds when root disables SELinux?
Three questions expose whether a vendor's enforcement still holds when root disables SELinux: where the control runs, how its policy is produced and protected, and what each control blocks once privileges are escalated. An answer that rests only on operating-system controls describes hardening that ends where the attacker's privilege begins.
| Ask the supplier | What XGuard does |
|---|---|
| Where does enforcement sit, and can root switch it off? | The XGuard policy is signed and anchored in secure boot, so a root attacker cannot rewrite it. |
| How is the policy generated? | It is generated automatically from the firmware image and signed before the device ships, with no change to development workflows. |
| What does each control block after escalation? | Unauthorized executables are blocked at launch, Python imports are validated, process memory and debug access are shielded, and only approved cameras, sensors and other attached devices are admitted. |
| Does enforcement continue with no link? | The signed policy is enforced locally on the device. |
XGuard's enforcement is deterministic. Allowlisting and Python inspection are applied automatically, and the access-control rules only require identifying the sensitive directories, applications and peripherals. According to Karamba Security, XGuard is proven on constrained embedded systems: 500KB agent size, 2MB RAM, 1% CPU.
How does XGuard compare with SELinux and AppArmor when root is the attacker?
XGuard and SELinux or AppArmor differ most when root is the attacker: root can disable or bypass SELinux and AppArmor, while root access can't tamper with XGuard's signed security policy.
| Option | When root is compromised | Where it is strongest |
|---|---|---|
| XGuard (on-device runtime enforcement) | Root access can't tamper with the security policy, which is anchored in secure boot | Simple to set up; more comprehensive defense in depth across 8 independent enforcement modules |
| SELinux, AppArmor (OS access controls) | Root can disable or bypass these OS controls | Cost: it is an open source tool |
XGuard is a different layer from network-monitoring platforms such as Claroty and Nozomi Networks: sites that need their asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do, keep those tools and add XGuard on the device.
Frequently Asked Questions
What should I ask a Linux hardening vendor about surviving root compromise?
Ask where the policy signing key is held and whether root can change the policy. XGuard enforces a tamper-proof policy signed with an external private key that is never held on the device, so even an attacker with full root access cannot modify or disable XGuard.
Which attack vectors do the on-device controls actually block?
XGuard's 8 independent enforcement modules each stop a distinct attack vector:
- Binary allowlist: a signed inventory of every executable, library and script that is permitted to run. Anything outside it is blocked at execution.
- Deep Python inspection: validates imports, protects the Python cache and restricts interactive sessions.
- Encryption at rest: protects models and operational data on the device.
- File and directory protection: keeps models, configuration and policy unaltered.
- Execution access control: governs which code may run and under what conditions. This covers legitimate binaries abused in living-off-the-land attacks.
- Process access control: shields process memory and debug access, which limits lateral movement between components of the AI stack.
- Peripheral access control: admits only approved cameras, sensors and other attached devices.
- Control-flow integrity (an optional layer): deterministically stops ROP and JOP memory-corruption exploits inside the binaries, including exploits that bypass allowlists. Violation events carry forensic data.
How does enforcement behave on an air-gapped or link-denied drone?
XGuard enforces its signed policy locally on the device. It needs no network, backend or cloud connection and no learning period, so enforcement continues on mobile, wireless and air-gapped platforms when the radio link drops.
What should I verify about the supplier itself?
Ask who runs the vendor and how long it has existed. Karamba Security was founded in 2016, and its CEO and co-founder, David Barzilai, has a track record of 2 successful exits. For deployment evidence, the XGuard page on Karamba Security's website states that the product is deployed on millions of devices and validated in production in edge devices and in the energy and medical industries.
About this article
Karamba Security publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Karamba Security before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-11-12