How Mobile Linux Differs from Desktop Linux

Mobile Linux Vs Desktop Linux Hero

Next year might be “the year of desktop Linux” in perpetuity, but mobile operating systems aren’t waiting around. They represent the fastest-growing of the Linux kernel, powering the vast majority of mobile devices. But how can the same kernel work on the desktop and a mobile system? Android doesn’t make much of a desktop operating system after all. The basic rules stay the same, but there are significant differences between mobile and desktop operating systems.

What Is Mobile Linux?

Mobile Vs Desktop Linux Ubntu Touch

Mobile Linux is any mobile operating system based on the Linux kernel, which was first created by Linux Torvalds in the 1990s. The kernel is the heart of the operating system: like the foundation of a building, it holds the rest of the computer system up and controls input and output operations.

Just like on the desktop, there is more than one Linux distro for mobile devices. Android is the most popular and best known, though it may have drifted away from the philosophical underpinnings of Linux. Android is the top mobile OS in terms of units sold worldwide, and it’s based on the Linux kernel. Google thoroughly developed the OS since that adaptation. The Linux philosophy is better maintained by Replicant, a FOSS fork of Android that emphasizes freedom and security.

Other Linux-based mobile operating systems also exist, and plenty more litter the open-source project graveyard. The most well-known distros include Linux kernel builds like PureOS, Ubuntu Touch (now community-supported by UBports), and postmarketOS, as well as Android ports like Replicant, LineageOS, and Plasma.

Of course, it should be noted that desktop Linux can be installed on nearly any mobile device. However, that’s not what we’re discussing here. We’ll be describing Linux distros built specifically for mobile devices.

Security and Permission Architecture

Mobile operating systems have different methods of ensuring user privacy. While most Linux-based mobile operating systems include some method for apps to communicate with one another, it’s rare for apps to have device access outside of their protected sandbox. Android includes fine-grained control over various device permissions, like writing to the local disk or communicating over your data connection.

Mobile Vs Desktop Linux Security

Desktop operating systems rarely include this level of permission control, especially not with an easy-to-understand user interface attached. While desktop Linux does include the well-known Unix-style file permissions, the permission toggles are typically limited to read, write, and execute. Mobile OSes, on the other hand, offer dozens of permissions that can be requested from the user.

While each distro uses their own precise system, most mature operating systems provide a high degree of control over which app can do what. Apps are rarely permitted to control the device completely and are limited in what operations they can perform, even with permissions.

Users are also limited in what data they can edit, though those restrictions can be overturned after obtaining root access. Root access and administrator privileges, which is available by default on desktop, is significantly harder to access, requiring device modifications to obtain root privileges.

Hardware and Device Flexibility

In general, mobile operating systems do not need to be as flexible as desktop operating systems. While a desktop computer can have literally infinite input and output configurations, mobile devices typically adopt only a single configuration: the one they were shipped with.

As a result, the many software packages on Linux that exist to support a huge variety of input, output, and storage devices can be removed. Fewer file formats and connectivity standards are supported, and only strictly necessary input and output packages will be included with the device. The distro is built with only what is necessary for the integrated deployment, with little consideration given to users’ aftermarket connectivity options.

Wireless or USB-C cable display capabilities exist today on higher-end devices, but this has only become an expected feature in recent years. While mobile operating systems get more powerful with each release, in general, mobile OSes are less flexible than desktop OSes.

Conclusion

You might think we missed the most obvious difference – the look and feel of the devices – but that obvious difference doesn’t necessarily decide how the underlying operating system works. The real differences live beneath the surface of the OS.

Mobile Linux is heavily customized for the deployed use and device, while desktop Linux distros have more generic packages. Despite these differences, the security and freedom of open-source software are maintained in most Linux-based mobile operating systems, just like on desktop.

Image credit: Vinodh Moodley

One comment

  1. Android uses SELinux, which is pre-installed on a distro like Fedora, which also had an Audit tool, which was included in previous versions (surely can be installed using the package manager dnf), but not anymore, probably because software has adapted so it’s no longer needed. Remember the last version with the tool, which if something is blocked, it could unblock it or tell you how to, if it understood the problem. I suspect there is a proper GUI available for all distros.

    Ubuntu and Ubuntu-based distros use AppArmor, which comes with predefined rules for everything from pre-installed system services, server services and even pre-installed GUI programs like Firefox. As a pro user and sysadmin I have never needed to create or edit a rule, but I’ve read several times questions and bug reports where the temporary or permanent solution is to create or edit a rule, which seems pretty straight forward. Once done once, you’ll know the basics if you actually care about what it does and not just copy/paste.

    SELinux is MUCH more integrated in everything on say a distro like Fedora. Both reading and setting SELinux permissions require special commands. Like ls won’t tell much more than that there is an SELinux permission on a file. A regular desktop user would not notice, no worries for them. But if say setting up a Apache + PHP and you want it to be able to write to files (text or SQLite), it isn’t enough to change file permissions with chmod – one must also set and apply SELinux permissions. The syntax is pretty complex for such an easy thing, and should definitely be improved, like making an SELinux command that behaves just like chmod, with another name, which sets and applies these settings.

    Now there are plenty of commands to do these things, it’s always tempting to just turn off SELinux which is fortunately easy, much easier than modifying it. It can be done on the fly as well, but does not always apply to all applications already constrained by it. Permanent solution to disable is easy to find in a /etc config file that tells you what the few settings there do and what alternatives you can set, like just changing it from enabled to disabled basically. This require a reboot, and IIRC is instant in taking effect after that, but if turned on again ALL the rules must be re-applied IIRC and that takes time.

    Some kind of progress indicator in % exists, maybe the Audit tool showed it or I just found it in syslog, the text file and/or journalctl. That’s why Android use SELinux. Much more complex, but also much more controls when having it set up. Special modules can be built if it does not already exist. Many modules are pre-installed that with a command can be listed and tells you what they do, like “Gives X access to do Y globally on the system”. IIRC these modules take a long time to load into SELinux and unload, almost like it seems to have frozen, where it should at least say “This may take a while” or always better, a progress bar. Probably setting a lot of settings. Unloading also takes a long time. IIRC once loaded it’ll be loaded on next boot as well. I once had to dig into building my own module. It was as simple as letting Apache (httpd) read all processes on the system, not just itself (through PHP or any language – as it had to be set to httpd not PHP). This was not documented ANYWHERE, and NO Google search had an answer. Really odd for something that enough people would want to write it somewhere.

    I don’t think I used the mailing list but rather commented on a post from a Red Hat employee who wrote about something similar, and making, compiling and loading an SELinux module to fix it. He gave me code that worked (needed to install one dev package to compile the code, IIRC just with make and the path to where the SELinux Makefile from this package is located). I did not understand the code at all. He gave me 2 modules to make, I think for the same thing, making it a little annoying for my Fedora users having to compile 2 modules, and loading each takes as said time, but at least I made a BASH script that did absolutely everything from downloading the dev package to loading.

    Then after some fiddling I found that I could indeed combine the 2 code examples (he gave me “examples that should work”, IDK what other solutions would’ve worked). That also taught me basic syntax (all gone now), which doesn’t allow necessarily your preferred way where other languages don’t care, and what order. Also IIRC found he had added some permission not actually necessary in this case. IIRC you make a .pp text file with the code, then make it with the Makefile path specified (he didn’t say that I think, only maybe that one needs the SELinux dev package, which I found at first try but just a wild guess, not a short logical name for what it does), and then you get a .ts file and that can be added/installed to the list of SELinux modules (name and version is specified in the code, not the name of the .ts file), and then one can load it.

    Similarly one can remove/uninstall an SELinux module, but hope it’s not possible to uninstall it if part of an RPM package (would be BAD). It seemed logical to him too that this should be documented, so he made an own blog post about it, quoting my question. Some technical details there that IIRC that “one can probably also achieve the same by this code” etc. Well, that was a pain! Luckily this guy on his personal blog responded quickly. Didn’t want to bother with asking what parts of the code does what and why it’s called so and so. We’re not talking hundreds of lines, maybe 10-15 after I found I could remove like 2 lines or whatever, but this could probably be reduced to much less if writing a long line in a place that lists an array basically, comma separated stuff at least, instead of the more readable file.

    I remember Google announced it would tighten security heavily on Android (without it affecting us developers, regular use or even custom ROMs and unlocking). Basically to tighten all files that no app or exploit in say PNGs should be able to touch from malware. That totally made sense. Maybe it adds a little overhead, at least devices when getting the upgrade from the last version without to the first with (longer installation/post-installation script). Custom ROMs use it as well. Suppose Google has added it to AOSP. SELinux is FOSS anyway, and it is GREAT that Google could do this with an already existing system rather than worst case, making a proprietary one making custom ROMs without root more easy to attack. This probably also started a big contribution from Google to the SELinux project, maybe before using it to “prepare it for Android”, but surely the more big players joining the community of a FOSS project, just like the kernel where Red Hat, at least a few years ago, was clearly the biggest individual contributor, but also other big names as IBM to Microsoft even.

Leave a Comment

Yeah! You've decided to leave a comment. That's fantastic! Check out our comment policy here. Let's have a personal and meaningful conversation.