Type Enforcement When Attackers Rename the Binary

SELinux vs AppArmor in 2026: Type Enforcement When Attackers Rename the Binary

We get one version of this question over and over: "If I rename the malware to something innocent and drop it in a trusted directory, does my mandatory access control still stop it?" It is a good question, because renaming and relocating a binary is one of the oldest tricks in the book, catalogued by MITRE as Masquerading (T1036). And the answer splits cleanly along the fault line we covered in our older SELinux vs AppArmor guide: it depends entirely on whether your MAC system makes decisions about the file or about the file's name.

The Rename Trick, from the Attacker's Chair

Put yourself on the offensive side for a second, because that is how you level up here. You have a foothold and a payload. You want it to run with as much reach as possible and survive a reboot. Two of your easiest moves are:

Copy the payload to a directory the system already trusts, and give it a boring name like cache-helper or ls.
Overwrite or shadow a legitimate binary that something privileged already launches.

Against a path-based control, both moves are aimed squarely at the weak spot: the decision is keyed on the string used to reach the file, not the file itself.

Why SELinux Type Enforcement Holds

SELinux does not care what you called the file. Every object carries a type label, stored on the inode, and the policy decides which domains may execute which types and what they transition into. Drop a payload into /tmp and it inherits tmp_t. A web server running as httpd_t has no allow rule to execute tmp_t, so it does not, no matter how you spell the filename:

$ cp /tmp/payload /tmp/ls
$ ls -Z /tmp/ls
unconfined_u:object_r:tmp_t:s0 /tmp/ls
# httpd_t has no allow rule for tmp_t:file execute -> denied, logged

Renaming it to ls does not hand it the domain of the real ls. The real /usr/bin/ls is bin_t; your copy in /tmp is tmp_t. The label followed the inode, and the policy decision followed the label. This is the whole point of type enforcement, and it is why the rename trick lands with a wet thud on a system in enforcing mode. No cheating with setenforce 0, which as every player here knows disqualifies your run.

Where AppArmor's Path Model Slips

AppArmor confines by profile paths. If a profile grants /usr/bin/** ix (inherit-execute anything under /usr/bin), then a file the attacker manages to write to /usr/bin/cache-helper inherits that grant because it matches the pattern. The profile was written to trust a location, and the attacker moved into the location. We are not dunking on AppArmor here, its profiles are far friendlier to write, but the structural fact stands: a name-based decision can be attacked by controlling the name. The hard-link and bind-mount variants of this are laid out in the older guide linked above, so we will not repeat them.

The Boss You Can't See: Where Even SELinux Stops Watching

Here is the part most comparison articles skip, and it is the one that actually matters in an incident. Type enforcement wins the rename fight, but there is a whole class of attacker behaviour it was never designed to catch:

Permissive domains. A single domain left permissive during troubleshooting logs the denial and allows the action anyway. The attacker operating in that domain is invisible to enforcement.
Unconfined contexts. Interactive shells often land in unconfined_t. An attacker who lands there is inside the walls, not outside them.
Living inside the allowed types. If a web app legitimately reads and writes httpd_sys_rw_content_t, a web shell doing the same thing is, to the policy, behaving perfectly. Nothing is denied because nothing violates the rules.
Boolean abuse. Flip httpd_can_network_connect and suddenly the exfiltration you would expect SELinux to block is explicitly permitted.

The uncomfortable truth is that SELinux is a control, not a camera. It enforces the policy you wrote and stays silent when an attacker operates within it. Catching the intruder who is working inside the allowed bounds, or in a permissive gap someone left open, is a detection problem, not an enforcement one, and it needs something watching host and endpoint behaviour continuously rather than a ruleset that only speaks up on a denial. Teams that cannot staff that watch around the clock increasingly pair their hardening with an outside detection function, the way Falconer Security frames endpoint hardening as enforcement plus continuous monitoring rather than either alone. The reference model for what enforcement itself should cover is still the SELinux Project's own Notebook, and the attacker techniques that live in the gap are catalogued across MITRE ATT&CK's Defense Evasion tactic, from masquerading to the permissive-context abuse above.

Achievement Unlocked: The Bottom Line

If you take one thing to the next level, take this. Against the rename-and-relocate trick, SELinux type enforcement is genuinely stronger than a path-based profile, because the label rides the inode and the policy follows the label. That is a real, provable win, and it is why we tell you to learn SELinux instead of disabling it. But do not mistake a passed challenge for a cleared game. Enforcement stops the moves that break your rules; it says nothing about the moves that stay inside them. Pair the MAC layer you just leveled up with detection that watches what happens after the policy says yes.