KernelSU SELinux Hiding Explained: How It Relates to SUSFS

TL;DR: SUSFS for KernelSU hides filesystem, mount and metadata traces, while KernelSU SELinux Hide sanitises selected SELinux-facing information visible to ordinary apps. They address different detection surfaces and can work together. Neither recreates a locked stock device, guarantees Play Integrity or ensures that any banking app will accept a modified phone.

By the PrivacyPortal team

Last updated 18 July 2026

KernelSU SELinux hiding and SUSFS are complementary kernel-side concealment features, not two names for the same technology. SELinux Hide limits what unprivileged applications can learn from selected SELinux interfaces. SUSFS, short for “SUS File System”, conceals root-related files, mounts and filesystem metadata when supported by the running kernel. A capable KernelSU or KernelSU Next build may use both, but compatibility depends on the device, kernel source, patch revision and userspace companion module. Back up everything before changing the boot chain: unlocking the bootloader normally wipes the phone, and flashing an incompatible kernel can prevent it from booting.

What KernelSU SELinux Hide actually does

SELinux, or Security-Enhanced Linux, is Android’s mandatory access-control system. It assigns security contexts to processes and files, then enforces rules governing which operations are allowed. A normal production phone should remain in SELinux enforcing mode.

KernelSU SELinux Hide does not simply switch SELinux off, make the device permissive or erase every sign of root. Its purpose is narrower: the kernel sanitises selected SELinux-facing results exposed to ordinary application user IDs. This can reduce inconsistencies that detection libraries might observe after kernel-level root modifications.

The implementation is visible in the KernelSU fork’s SELinux Hide declarations and SELinux Hide implementation. Behaviour can change between forks and commits, so the source used to build a kernel matters more than a manager application’s version label.

KernelSU’s source exposes SELinux hiding through kernel/feature/selinux_hide.h and kernel/feature/selinux_hide.c.

Image caption: KernelSU SELinux Hide filters a narrow detection surface while SELinux continues enforcing Android’s access-control policy.

What SUSFS for KernelSU hides

SUSFS for KernelSU operates at the filesystem and virtual filesystem layer. A correctly patched kernel can conceal selected paths, mounts and related metadata before an ordinary application receives the result. This is materially different from a userspace module attempting to alter output after the kernel has exposed it.

The architecture normally has two parts:

• Kernel support: the running kernel must contain a compatible SUSFS patch or implementation.
• Userspace control: a matching SUSFS4KSU companion module or integrated manager component configures supported hiding features.

A module ZIP cannot add missing kernel code by itself. If a KernelSU module interface reports “SusFS not supported”, repeatedly reinstalling the userspace module will not solve the problem. The phone needs a compatible kernel build.

SUSFS may conceal evidence such as root-related paths, altered mount arrangements and suspicious filesystem metadata. Exact capabilities depend on the patch revision and its KernelSU integration. Review the official SUSFS4KSU project and the documentation supplied by the kernel maintainer rather than assuming that instructions for another device apply to yours.

As verified on 18 July 2026, SUSFS is a kernel capability; its companion module is not a substitute for a SUSFS-patched kernel.

SELinux Hide and SUSFS compared

Question	KernelSU SELinux Hide	SUSFS for KernelSU
Primary detection surface	Selected SELinux-facing information	Filesystem paths, mounts and metadata
Runs at kernel level	Yes	Yes, when compiled or integrated into the kernel
Standalone module sufficient	No	No; kernel support is required
Should SELinux remain enforcing	Yes	Yes
Works with Magisk alone	No	No; Magisk does not provide the required KernelSU kernel integration
Guarantees app compatibility	No	No
Can be used together	Yes, if the particular kernel build implements compatible versions of both

The practical decision is not “SELinux Hide or SUSFS?” A well-maintained kernel can use SELinux Hide for SELinux-facing artefacts and SUSFS for filesystem-facing artefacts. Adding more concealment components is not automatically better, however. Overlapping modules can produce abnormal mount layouts, duplicated rules or breakage that itself becomes detectable.

What these features cannot hide

Root detection is not limited to files and SELinux output. Applications and remote services can consider bootloader state, Android Verified Boot data, hardware-backed key attestation, ROM signatures, build properties, loaded native libraries, debugger indicators and behavioural anomalies.

Play Integrity is also a server-informed attestation system, not a single local test. Passing one local root checker does not prove that Play Integrity verdicts will pass, and obtaining a verdict today does not guarantee the same result after an application, service or Google Play system update.

Banking apps use their own policies and may change detection providers without notice. PrivacyPortal does not promise that KernelSU SELinux Hide, SUSFS, Play Integrity Fix, Tricky Store or any combination will defeat a particular bank’s checks.

Neither SELinux Hide nor SUSFS restores the security guarantees of an unmodified phone with a locked bootloader and stock verified software.

A modified boot chain can also reduce physical security. Root access gives approved processes extensive power, while a malicious or poorly written module can access sensitive data. Only install components whose source, maintainer and release provenance you can verify.

Prerequisites before installing SUSFS

Start with a complete backup stored away from the phone. Include photos, authenticator recovery codes, messaging backups and any files needed to return to stock. Bootloader unlocking normally performs a factory reset.

You will also need:

• A bootloader-unlockable device that you own and are authorised to modify.
• The exact factory image for the installed build, including the original boot or init_boot image.
• A device-specific KernelSU or KernelSU Next kernel explicitly marked as supporting SUSFS.
• A matching KernelSU manager and, where required, the SUSFS4KSU userspace companion module.
• Android platform tools on a computer and a tested USB cable.
• A documented recovery route, such as fastboot access or the manufacturer’s restore utility.

Match the full kernel release string, Android generation, device codename and ROM build. A label such as “6.1 Android 14” is not precise enough. For example, a kernel advertised for 6.1.25-android14 should not be treated as interchangeable with every other 6.1-based build.

The official KernelSU device-support guidance explains why supported installation methods vary. GKI, or Generic Kernel Image, devices may accept a suitable prebuilt image; non-GKI devices generally require a device-specific kernel built from source.

How to install and verify SUSFS with KernelSU

This procedure is deliberately partition-aware. Some phones use boot, others use init_boot, vendor_boot or a device-specific packaging process. Never guess the destination partition.

1. Back up and record the current state. Save important data off-device. Record the exact Android build number, device codename, active slot, kernel release string and KernelSU manager version. Confirm that the stock image can be downloaded before unlocking anything.
2. Check the kernel’s documentation. Confirm that the release explicitly supports your device, installed ROM build, KernelSU family and SUSFS revision. “KernelSU compatible” does not automatically mean “SUSFS compatible”. Avoid images redistributed without source, checksums or maintainer notes.
3. Unlock the bootloader using the manufacturer’s documented process. Expect a complete data wipe. Re-enable developer options and USB debugging only after initial setup. An unlocked-boot warning at startup is normal and is not removed by SUSFS.
4. Preserve the original image. Keep an untouched copy of the factory boot-chain image for the current build. Do not rely on downloading it after a failed flash, especially if the manufacturer removes older packages.
5. Install the supported KernelSU manager. Use the manager named by the kernel maintainer, such as KernelSU Manager or KernelSU Next Manager. Manager, kernel and SUSFS revisions must be compatible; installing the newest manager over an older custom kernel can produce misleading status information.
6. Flash the verified kernel image by its documented method. Use fastboot, fastbootd, recovery or Horizon Kernel Flasher only when the maintainer specifically supports that route. If documentation identifies boot, flash only boot; if it identifies init_boot, use that partition instead. Do not flash both “to be safe”.
7. Boot once before adding modules. Confirm that Android starts, touch, Wi-Fi, mobile data, cameras and charging work, and KernelSU reports an installed kernel implementation. If the phone bootloops, restore the original image rather than adding more modules.
8. Install the matching SUSFS userspace component if required. Obtain the named SUSFS4KSU package from the “Modules, apps & files to try” section supplied with this guide or from the kernel maintainer’s release notes. Some integrated builds provide the necessary controls themselves, so follow that build’s instructions.
9. Reboot and verify support. Open the SUSFS module interface or KernelSU WebUI. It should report supported or show functioning SUSFS controls, not “SusFS not supported”. Check that SELinux remains enforcing. A permissive result is a security problem, not successful hiding.
10. Test stability before compatibility. Check sleep, battery use, calls, Bluetooth, storage access and OTA behaviour over several restarts. Then test non-sensitive root-checking tools and Play Integrity separately. Do not use a successful result as proof that a banking app will remain compatible.

Image caption: Record the device codename, complete kernel string and target partition before selecting any KernelSU kernel image.

A practical decision framework

Choose a SUSFS-capable setup only when all four conditions are true:

• The device has an unlockable bootloader and a reliable stock-restoration path.
• A reputable maintainer supports the exact device and ROM build.
• The kernel release explicitly documents compatible KernelSU and SUSFS revisions.
• You accept possible OTA disruption, app rejection, increased maintenance and reduced security assurance.

Stay with stock software when banking reliability, workplace device compliance or hardware-backed security is more important than root access. Consider a conventional KernelSU build without SUSFS when you need root for development but do not need concealment. Choose a combined SELinux Hide and SUSFS kernel only when the implementation is maintained as one tested stack.

For broader preparation, read PrivacyPortal’s Android bootloader unlocking and backup guide and KernelSU versus Magisk guide before changing the boot image.

Common failure modes and recovery

The interface says “SusFS not supported”

The running kernel lacks compatible SUSFS support, the wrong image booted, or the userspace component does not match the kernel patch. Reinstalling the same module cannot create the missing kernel implementation. Verify the active slot and kernel string, then consult the release notes.

The phone bootloops after flashing

Stop experimenting and restore the untouched image for the same firmware build using the documented partition and flashing mode. Common causes include the wrong device build, wrong partition, incompatible kernel modules or a stale image from another OTA version.

Integrity worsens after adding more modules

Module stacks can conflict. In practice, aggressive path-hiding lists and post-mount scripts may overlap with SUSFS, create unusual results or hide files Android needs. Integrity Box has had community-reported conflicts with some SUSFS configurations. Disable additions one at a time and test after every reboot.

OTA installation fails

A custom boot-chain image can prevent incremental over-the-air updates from applying. Restore the matching stock image before updating, or follow the device maintainer’s documented update process. Never assume that an update preserves root or that an older patched image is safe on the new build.

Image caption: A recoverable setup keeps the original image, factory package and correct flashing instructions available before a modified kernel is tested.

Frequently asked questions

Is KernelSU SELinux Hide the same as SUSFS?

No. SELinux Hide sanitises selected SELinux-facing results exposed to ordinary app user IDs. SUSFS targets filesystem paths, mounts and metadata. They address different detection surfaces and may be integrated into the same kernel.

Can I install SUSFS as an ordinary KernelSU module?

Not on an unsupported kernel. The userspace SUSFS4KSU module configures kernel functionality; it cannot add the required kernel patch by itself. The running kernel must explicitly support a compatible SUSFS implementation.

Does SUSFS work with Magisk?

Not as a normal Magisk-only installation. SUSFS for KernelSU depends on kernel-side integration associated with KernelSU or a compatible fork. A Magisk-patched boot image is not a substitute for a KernelSU and SUSFS-enabled kernel.

Does SUSFS guarantee Strong Integrity or banking-app access?

No. Attestation and banking checks can include bootloader state, hardware-backed evidence, ROM identity and server-side policy. Results vary by device and can change after updates. No responsible guide can guarantee acceptance by a specific app.

Should SELinux be permissive when using SELinux Hide?

No. SELinux should remain enforcing. Permissive mode weakens Android’s security model and can itself be detected. SELinux Hide is concealment of selected exposed information, not permission to disable enforcement.

Is KernelSU Next required for SUSFS?

Not universally, but KernelSU Next is a common integration path. Standard KernelSU and other forks may support SUSFS when their kernel has been patched appropriately. Compatibility is determined by the actual kernel source and release documentation, not the manager’s name alone.

Can SUSFS permanently brick a phone?

Flashing an incompatible image can make a phone unbootable and, on some devices, difficult to recover. A bootloop is often recoverable through fastboot or a manufacturer restore tool, but recovery is never guaranteed. Back up first, retain stock images and never relock the bootloader while modified partitions remain installed.