Understanding Virtual Filesystems
In the Linux architecture, certain directories are not stored on physical storage media but are generated dynamically by the kernel. These are known as virtual filesystems (VFS). Common examples include /proc, which exposes process information, /sys, which provides hardware and driver details, and /sys/fs/selinux, which serves as the interface for the Security Enhanced Linux subsystem.
Unlike ext4 or xfs, these filesystems have no underlying block device. They exist solely in memory to provide a standardized interface between the kernel and user-space applications. Because they are not backed by a device, the concept of "mounting" them from a disk image or partition does not apply in the traditional sense. The kernel handles their lifecycle entirely internally.
The Role of selinuxfs
The selinuxfs filesystem is specifically designed to allow user-space security modules to interact with the SELinux policy loaded in the kernel. It provides files that can be read or written to enable, disable, or query security contexts. For example, writing "1" to /sys/fs/selinux/enforce toggles enforcement mode.
This interaction requires direct access to kernel data structures. Allowing arbitrary users or processes to mount this filesystem manually would create significant security vulnerabilities and stability issues. Therefore, the kernel restricts its availability to specific mount points defined at boot time.
Why Manual Mounting Fails
When you attempt to run a command like mount -t selinuxfs none /sys/fs/selinux, the kernel rejects the request. The do_mount syscall checks the type of filesystem being requested. For virtual filesystems, the implementation does not support the mount operation because there is no superblock to initialize from disk.
The error typically returned is EINVAL (Invalid Argument) or EACCES (Permission Denied), depending on the kernel version and configuration. This behavior is intentional. If the filesystem were already mounted, attempting to mount it again might succeed due to bind mounts, but creating a new instance from scratch is prohibited.
Checking Existing Mounts
To verify if selinuxfs is active, use the mount command without arguments or check /proc/mounts. Look for an entry similar to:
none on /sys/fs/selinux type selinuxfs (rw,nosuid,nodev,noexec,relatime)If this line exists, the filesystem is already mounted correctly by the init system. No further action is required. If it is missing, your system may be running without SELinux, or the init system failed to mount it during startup.
Proper Initialization via Init Systems
On modern Linux distributions, including Android, the mounting of virtual filesystems is handled by init scripts or systemd units. These scripts ensure that the necessary mount points are created and populated before any service that depends on them starts.
- Systemd: Uses
systemd-sysctl.serviceand specific unit files to mount virtual filesystems. Thetmp.mountanddevpts.mountunits often handle related virtual FS tasks alongside SELinux setup. - Android Init: Android uses its own init daemon which reads
.rcfiles. These files contain commands likemount_allor specificmountdirectives for virtual filesystems during the early boot phase.
Attempting to bypass these mechanisms by calling the syscall directly will almost always fail unless you are modifying the kernel source itself.
Debugging Boot Failures
If selinuxfs is not present after boot, check the kernel log for errors. Use dmesg | grep -i selinux to see if the kernel attempted to load the module but failed. Common reasons include:
- The kernel was compiled without SELinux support (
CONFIG_SECURITY_SELINUX=n). - The SELinux policy file is corrupted or incompatible with the running kernel version.
- The init system failed to execute the mount command due to permission issues or syntax errors in the configuration script.
Alternatives and Workarounds
If you need to manipulate SELinux settings, do not try to remount the filesystem. Instead, use the standard tools provided by the policycoreutils package or Android's setprop and getenforce commands. For debugging, you can temporarily disable enforcement by writing to the enforce file if you have root privileges, but this does not require unmounting or remounting.
In rare cases where the filesystem appears stale, rebooting the system is the only reliable way to reset its state. Unmounting it manually is possible with umount /sys/fs/selinux, but doing so while the system is running can break many security-related services immediately.
Frequently Asked Questions
Can I unmount selinuxfs to free up resources?
No, unmounting selinuxfs is dangerous and generally unsupported while the system is active. Many critical services rely on reading security contexts from this filesystem. Removing it will likely cause immediate crashes or security violations in dependent applications.
Why does my Android device show selinuxfs as mounted even though I didn't mount it?
Android's init system automatically mounts all required virtual filesystems during the boot sequence. This is hardcoded into the device's init configuration files to ensure SELinux policies are enforced from the earliest possible stage of the operating system launch.
What should I do if selinuxfs is missing after a kernel update?
Reboot the device to allow the init system to re-run its mounting scripts. If it remains missing, check if the new kernel was compiled with SELinux enabled. You may also need to reinstall the SELinux policy packages to match the new kernel version.
Is it safe to use bind mounts on selinuxfs?
Bind mounting parts of selinuxfs is possible but risky. It can expose sensitive security controls to unauthorized processes if permissions are not strictly managed. Only experienced administrators should experiment with bind mounts on this filesystem.
How can I check if SELinux is actually enforcing policies?
Use the command getenforce to see the current mode. It will return Enforcing, Permissive, or Disabled. Do not rely on the presence of the mount point alone, as some minimal systems may have the filesystem mounted but SELinux functionality disabled via kernel parameters.