The Anti-virus Times

piątek, 27 lutego 2026

Many of our readers probably know that Android rests on the foundation of a monolithic Linux kernel that has been optimised for mobile devices. The kernel incorporates core OS services, such as memory and process management, device drivers, and, of course, security features. This doesn't mean that Android is yet another Linux distribution; after all, its multilayer architecture also encompasses a variety of other components that enable actual devices to operate, apps to be run, and ultimately the user experience to be defined. However, it is the Linux kernel that outfits Android with the most fundamental security feature of all Unix-like systems—the access permission model and root privileges. In today's issue, we'll talk about how root permissions influence the design and operation of antiviruses under Android and consider the options and risks that are involved.

What are root permissions and why do we need them?

In all general-purpose operating systems, including Android, iOS, Linux, macOS, and Windows, every application runs under a specific user account, which provides it with a pre-defined set of permissions or privileges. This arrangement represents one of the basic information security principles—namely, the access control model. It allows a system to control which digital resources—files, memory, processes, network connections and hardware components—an application can use. This isolation and restriction mechanism protects the operating system and data from incorrect or malicious actions performed by applications and users. Apple's iOS is a prime example of the tightest security restrictions: each application runs in its own sandbox and neither the program nor the user can access system components (unless a vulnerability is exploited).

But let's get back to Android. Root permissions in Android provide privileged access to the operating system—similarly to superuser accounts under Linux. By default, root privileges are unavailable, and the system is configured to maintain a security level that is deemed sufficient for all intents and purposes as each app runs in an isolated environment with limited permissions, and its access to resources and data on the device is thus controlled. Meanwhile, core system processes have elevated privileges to ensure that the OS operates normally. One could call it Android's BOH ("Back of House")—a no-go area for ordinary apps and users. However, unlike iOS, where the option to obtain elevated privileges hardly even exists, Android's architecture allows for the possibility to get root permissions and, consequently, full control over the operating system.

Root permissions are closely related to Linux's UID (user identifier) concept. It's a unique number assigned to each user account under Linux and shared by all of the processes that get started on the user's behalf. And this is where a considerable difference lies between conventional multi-user Unix-like systems and the Android mobile. In Android, a UID is assigned to each app rather than to an actual user account (in this case, an app or a process can be regarded as a virtual user). Consequently, the UID is used to keep apps isolated and manage access permissions: all non-system apps operate under limited privilege UIDs, which the operating system uses to control their permissions to access "someone else's" data and core system components.

Root permissions make the isolation design irrelevant. If an app has gained root privileges, it means that its process has been assigned UID 0. UID 0 is assigned to the superuser account that enjoys unrestricted access to all files, processes and system resources—since the kernel imposes no restrictions on the processes associated with this UID. In reality, this means that a user whose apps are assigned UID 0 gains ultimate control over the device, which provides them with a wide variety of system customisation and administration options—the very reason why many users prefer Android devices, since root permissions make this relatively open platform even more flexible and customisable.

It is important to remember that a rooted device doesn't run all of its apps with superuser privileges (UID 0) by default. Rather, the user can gain root permissions at any moment to perform the tasks they need to in the system. That's why most third-party applications still run in their reasonably secure sandboxes with limited permissions and have unique UIDs even on a rooted device. After acquiring the key to the OS's BOH, the user can simply give it to any app they want.

Inevitable security loopholes

You probably have already guessed what the perils of such system modification can be. In our publications, we often talk about security issues related to using elevated privileges—be it Android, Windows or any other OS. Let's consider those lying on the surface.

As we've mentioned before, sandboxing is the backbone of Android security. An app that has gained root privileges breaks out of its jail and its operation is no longer controlled by the operating system. So, it can access other apps' data, including user data, delete or modify system files and transfer them across the network, install other programs, change system settings and more. If a knowledgeable user initiates and controls all of these actions, that's one thing. But if a device owner is not quite sure of what they're doing and/or the app they're using hasn't been tested thoroughly, this situation is more dangerous. But the worst-case scenario is when a device like that gets caught in the crosshairs of an attacker or a malicious program.

More advanced trojans will attempt to elevate their privileges in a system to freely execute arbitrary code—thus, effectively gaining full control over the device. In a system where root privileges are not readily available, this would involve exploiting vulnerabilities, which can be very tricky. To compromise the device, an intruder would have to circumvent kernel security mechanisms by taking advantage of a software loophole in order to operate outside of its sandbox. Attacking a device that already has root access unlocked is much easier. Trojans appear on a device in the guise of legitimate apps and prompt the user to grant them root permissions. If the user taps "Allow", the trojan is assigned UID 0 to wreak havoc at its leisure.

Indeed, vulnerability exploits allow malware to mount attacks in a more covert fashion by elevating its privileges in the background without displaying user prompts. However, such attacks are much less common than those based on social engineering techniques that rely on deception and user carelessness. That's why owners of rooted devices are more at risk.

The overall Android security situation is also affected by a number of additional factors. First, third-party applications can be installed by using unverified APK files. Second, malicious software can also find a way into official application catalogues, such as Google Play.

Bear in mind that a malicious program doesn't necessarily need root permissions to inflict severe damage or steal data. A trojan can actually make do with the standard permissions that legitimate apps request to use shared system resources. A typical example: a torch app requesting access to contacts, SMS and GPS or other features and components. In this case, the disguised trojan doesn't break conventional system security rules—it doesn't attempt to reach beyond its allocated sandbox; instead, it gains access to the data it's after with the user's consent. Unfortunately, deceiving an actual human being is often much easier than gaining root privileges on modern and up-to-date devices.

The variety of threats that exist for Android, coupled with the substantial amounts of sensitive data we store and process on our devices, lead us to conclude that reliable antivirus protection is a must-have.

Root access and the operation of an antivirus

We at Doctor Web believe that an antivirus should be able to operate properly and effectively on a device without gaining root access. Obtaining root permissions is a non-conventional operation, albeit one provided for by the system design, and the user needs to understand what they're doing and be aware of the risks involved as well as the potential adverse consequences. That's why Dr.Web for Android does not request root permissions from the user, and, on top of that, the product's stable operation on rooted devices is not officially guaranteed. Moreover, unlocked root access is regarded as an unpatched vulnerability, and we've provided ample reasoning above to justify our stance. At the same time, Dr.Web can take advantage of readily available root permissions for more in-depth scans.

For example, if a device has been rooted, the user can select the /sbin and /data directories located in the device's root directory as objects for scanning. These directories are Android's critical system areas and no user or standard apps can access them without root privileges—even more so in the OS's more recent versions. This, however, doesn't mean that the benefits of unlocking root access outweigh the risks. As far as system security is concerned, it is actually the other way around. Dr.Web effectively protects devices even if it runs in a conventional sandbox and only has a standard set of permissions to work with. The file monitor SpIDer Guard can keep track of changes in the device's system areas without root permissions and notify the user whenever an executable file is created, modified or deleted. It still has read-access for these areas, which is sufficient for signature-based and heuristic system inspection. In addition, the antivirus relies on standard system features, such as file system event monitoring in order to track changes in system directories. The limitations of operating without root permissions won't allow the antivirus to prevent unauthorised modification in the off-limit areas or independently modify them.

Therefore, the complete absence of root permissions improves the device's security and makes the antivirus's job easier. It will keep protecting a device effectively from all kinds of threats, and malware will have a hard time breaking out of the sandbox prison to make itself untouchable for the antivirus. With root privileges at its disposal, an antivirus can acquire extra capabilities for threat neutralisation, but the threats will get similar upgrades to match those of the antivirus. At the same time, the device becomes much more vulnerable—and even more so if the user is careless or lacks a sufficient IT background.