[Feature] Improve security measurements

[secretmango]

Is your feature request related to a problem? Please describe.

Waydroid currently is based on LineageOS based on Android 11.

LineageOS is neither as secure, nor as private as currently possible on Android, from the the work of GrapheneOS.

Security:

• hardened malloc
• secure app spawning
• vanadium browser and webview
• hardened PDF viewer

Privacy

• storage scopes (GOS)
• contact scopes (GOS)
• network permission (GOS)
• Captive portal check (which will always ping Google!) disabled or on custom server
• Same for Connectivity check
• (SUPL server replacement and metadata cleaning. Like a VPN for A-GPs)

Compatibility

• GrapheneOS's sandboxed Play Services
• native code debugging switch

Describe the solution you'd like.

Build the Waydroid image based on GrapheneOS.

Describe alternatives you've considered.

Waydroid currently is pretty insecure as it is very outdated. Not using it is my poor alternative.

BlissOS in a VM didnt work for me, but would be way more secure.

• CaptivePortalController on F-Droid can replace Captive portal and ConnectivityCheck server
• Magisk module for changing SUPL server

Additional context

Awesome project! Thank you so much for just running Android on Linux, on Wayland! Using a CLI! And all that App integration, its amazing.

But first it needs to update from Android 11

[ChrysoliteAzalea]

SELinux enabled (!) and enforcing
hardened Kernel

Waydroid is a purely user-space process, using hardened kernel and enabling SELinux is users' responsibility. Currently, we provide AppArmor policies (however, in complain mode but users can switch them to enforce mode if they want), and, as far as I know, Fedora packages SELinux policies for Waydroid.

secure and modern Camera (all GrapheneOS)

I don't even know whether Waydroid supports camera without custom modifications (I couldn't get it working).

storage scopes (GOS)

Already enabled -- mobile apps need granted permission to have full access to the storage, otherwise they either couldn't access it at all, or, if they are granted scoped access, can only access files of certain types in read-only mode (all accesses go through MediaProvider due to FUSE mount).

Other points are valid, you can compile your own image from sources using Waydroid patches, propose patches at the android_vendor_waydroid project, or use Magisk for custom modifications.

[secretmango]

true (facepalm) forgot its a container...

thanks! I will look into that.

[mkljczk]

Keeping the actually relevant ones:

• storage scopes
• network permission
• Captive portal check (which will always ping Google!) disabled or on custom server, Having Connectivity check disabled or on custom server (aren't both the same thing?)
• GrapheneOS's sandboxed Play Services
• CalyxOS's less secure, more private microG (but not in a sandbox!)
• microG's replacement of Google Maps with OSM

Both GrapheneOS camera app and PDF viewer can be installed on other OS'es. The thing I think would make the most sense for Waydroid is porting the sandboxed Play Services, so there's no need for separate images for gapps and vanilla

Already enabled -- mobile apps need granted permission to have full access to the storage

Storage scopes on GrapheneOS work differently, supporting legacy apps and everything that requires full access to storage.

[secretmango]

I edited the comment. microG is a security mess and should not be implemented. UnifiedNLP should be revived and only used if it works as an unprivileged app.

Adding:

• rebase to GrapheneOS (takes care of all the features), otherwise:
• contact scopes
• hardened webview, providing vanadium and the pdf viewer
• sandboxed play compatibility app integrated
• unprivileged UnifiedNLP (project is currently only available within microg)

also Android 14 is supposed to have a Desktop mode, not sure how it is different from the current implementation.

[thestinger]

Waydroid doesn't have the most basic parts of the Android security model intact. SELinux is not an additional layer of security in Android but rather a huge part of the core security model. There's little point in any hardening when apps aren't being sandboxed and have more access to the kernel, hardware, etc. than they normally do on Android. Preserve the standard security model to the extent possible on a less secure host before worrying about hardening.

[thestinger]

@firefoxlover

I edited the comment. microG is a security mess and should not be implemented. UnifiedNLP should be revived and only used if it works as an unprivileged app.

UnifiedNLP is a dead project. Look at the repository. It was merged into microG and can't be used without it anymore. It's also not a secure or correct approach to making location providers.

[thestinger]

@firefoxlover Not really clear why you're listing out a specific subset of GrapheneOS privacy and security features. Waydroid should probably simply upgrade to AOSP 14 and stop disabling most of the Android security model. Running everything in a hardware acceleration VM with CPU acceleration is a better approach since it allows using a kernel supporting the expected features and with the standard AOSP hardening. I don't think the project realizes that SELinux is a huge part of the core Android security model and that by disabling it, apps aren't sandboxed anymore, have far more access to the kernel and it ends up being far less secure than running the apps on Android. The use of namespaces really doesn't make up for this. Many users wrongly believe Waydroid is acting as an additional sandbox when in reality it's resulting in the apps not being sandboxed in the standard way and having more rather than less kernel / hardware access along with not being isolated from each other. Rather than worrying about hardening it makes more sense to focus on moving to the only version of the OS with full security support (AOSP 14 QPR2) rather than High/Critical severity backports (ending soon for Android 11), keeping the security model intact (SELinux is a huge part of that) along with avoiding the large reduction in security from LineageOS changes. No need to use an OS with a whole bunch of hacks for broad device support for a container/VM.

[thestinger]

@ChrysoliteAzalea SELinux is the main implementation of the Android app sandbox. Apps aren't sandboxed without it. It's not treated as an additional layer of security in Android and the basics of the privacy and security model are not intact without it. It seems you're referring to SELinux policies on the host, but it's the SELinux policies for Android which are important to protect the kernel from apps, to protect apps from each other and to keep the overall OS security model intact. Protecting userspace on the host from the container with SELinux policy isn't the same thing as the Android SELinux-based security model being kept intact.

[thestinger]

@mkljczk This is a very strange comment that's highly inaccurate.

Keeping the actually relevant ones:

That's completely wrong and is missing nearly all of what's provided from either a privacy or security perspective.

Captive portal check (which will always ping Google!) disabled or on custom server, Having Connectivity check disabled or on custom server (aren't both the same thing?)

Not in any way the same thing and not clear why you focused specifically on this default connection over others.

CalyxOS's less secure, more private microG (but not in a sandbox!)

microG is not a CalyxOS project. They do like to take credit for projects which they didn't create such as Seedvault, but I'm not aware of them trying to pull that with this one.

You have the privacy aspect completely backwards. You have the common misconception that GrapheneOS is focused on security rather than privacy which is completely wrong, and you're promoting a far less private operating system that's also highly insecure. It doesn't have comparable privacy features, not only security features. It doesn't preserve the standard security. Using their approach to compatibility with Google Play gives strictly more access to Google Play components than sandboxed Google Play on GrapheneOS. When using microG, you're still running Google Play as part of each app using it but you seem to have the misconception that you're avoiding it by using microG. microG also downloads/runs Google Play components and those get run with all the privileged access it has. You have the mistaken impression that sandboxing is about security rather than privacy. It's about privacy and strong security is needed to make it work. Sandboxed Google Play means Google Play running in the same app sandbox as the apps using the Google Play libraries. The whole point is that it's the same sandbox with zero additional access compared to any other regular app, and no standard permissions need to be granted to it.

Storage scopes on GrapheneOS work differently, supporting legacy apps and everything that requires full access to storage.

This is completely untrue. Storage Scopes are fully compatible with all Android apps.

@mkljczk Please avoid making these inaccurate claims about GrapheneOS going forward.

[ChrysoliteAzalea]

@thestinger The problem is that it would require enabling SELinux on the host (because you cannot enable SELinux for some processes and disable for other), and the rest of the system may not be prepared to use it (also, users may be required to load Android-specific policies). And enabling SELinux would require disabling AppArmor -- another mandatory access control implementation that some desktop distros depend on. The only possible option I see is making both SELinux-aware builds (that require SELinux) and non-SELinux builds (in fact, there are AppArmor policies for Waydroid, but they are more about preventing container escape, the problem is that on smartphones, the SELinux domain transition decisions are made by zygote, which is not aware of AppArmor).

Running everything in a hardware acceleration VM with CPU acceleration is a better approach since it allows using a kernel supporting the expected features and with the standard AOSP hardening.

That may be the solution for lots of problems (not only security, but also portability -- virtual machines don't require Linux on the host to run Android). Waydroid is a container, which may be better for performance and desktop integration, but worse for privacy and security (it's also a privileged container, so what's really important is preventing apps from getting root/capabilities, and if we want to make Waydroid more secure, we would have to consider supporting unprivileged containers).

[thestinger]

The problem is that it would require enabling SELinux on the host (because you cannot enable SELinux for some processes and disable for other), and the rest of the system may not be prepared to use it (also, users may be required to load Android-specific policies).

It is possible to use SELinux in an essentially no-op mode and MCS/MLS can be used to provide container support, unlike most of the other security modules.

And enabling SELinux would require disabling AppArmor

That's currently the case, and a cost of using namespaces rather than a VM.

The only possible option I see is making both SELinux-aware builds (that require SELinux) and non-SELinux builds (in fact, there are AppArmor policies for Waydroid, but they are more about preventing container escape, the problem is that on smartphones, the SELinux domain transition decisions are made by zygote, which is not aware of AppArmor).

The main escape vector is a kernel exploit, and far more kernel attack surface is exposed without SELinux along with not having comparable kernel hardening like the usual PAC/BTI, ShadowCallStack, type-based CFI and lots of other assorted things not being enabled by most distributions. That's just baseline AOSP stuff. Android heavily uses SELinux as part of the core security model and the app sandbox depends on it. SELinux isn't just an additional layer on top. Most of the low-level app sandbox privacy and security policy is implemented directly through it. The high-level policy also depends on it. It's not simply an optional part of the Android application model. Stuff will run without it, but not with the app sandbox and permission / access control model intact. SELinux not being enabled is only a possibility for development.

but worse for privacy and security (it's also a privileged container, so what's really important is preventing apps from getting root/capabilities, and if we want to make Waydroid more secure, we would have to consider supporting unprivileged containers).

Preventing that largely depends on having the normal sandbox for the apps. It's also very important to protect apps from each other and the user's data within it from the apps. SELinux is what's used for a whole lot of this on Android. It's how the app sandbox is made and is how they do a lot of the kernel attack surface reduction too. For example, it's how apps are preventing from using things like io_uring and eBPF. Having a kernel without the expected hardening / security policy configuration enabled is also an issue beyond this. For example, it's not expected that unprivileged user namespaces are available among many other things. There's a kernel/configs repository with mandatory and recommended kernel configuration including to maintain the security properties. The generic kernels also have a whole lot of hardening enabled.

The main thing to start with would really be updating to the current version (Android 14 QPR2), using AOSP directly rather than a fork rolling back security a lot and keeping SELinux enabled. Supporting using it without SELinux is perfectly fine if users are informed that it means there isn't a working app sandbox within the container and container escapes are far easier. Right now, many people believe Waydroid is acting as a sandbox around the app but it's really doing the opposite but removing most of the standard low-level security model while having privileged access within it.

It's not really considered a vulnerability for an app to get system level access in a development build of Android with SELinux disabled. SELinux is a huge portion of how basic things are enforced.

[LFRon]

SELinux enabled (!) and enforcing
hardened Kernel

Waydroid is a purely user-space process, using hardened kernel and enabling SELinux is users' responsibility. Currently, we provide AppArmor policies (however, in complain mode but users can switch them to enforce mode if they want), and, as far as I know, Fedora packages SELinux policies for Waydroid.

secure and modern Camera (all GrapheneOS)

I don't even know whether Waydroid supports camera without custom modifications (I couldn't get it working).

storage scopes (GOS)

Already enabled -- mobile apps need granted permission to have full access to the storage, otherwise they either couldn't access it at all, or, if they are granted scoped access, can only access files of certain types in read-only mode (all accesses go through MediaProvider due to FUSE mount).

Other points are valid, you can compile your own image from sources using Waydroid patches, propose patches at the android_vendor_waydroid project, or use Magisk for custom modifications.

But if there is a way to just use SELinux inside the Waydroid(LXC) through this?:SELinuxProject/selinux-kernel@975a1e0

I use Ubuntu and I hope to use AppArmor inside and run SELinux inside Android because many Android Apps and frameworks like ZygiskNext and LSPosed all need SELinux to be opened

[secretmango]

Are there updates on porting to Android 14? Android 11 is EOL since quite a while.

[odomingao]

Would it be possible to tighten the apparmor profiles? They all have the sys_admin capability and others...