• General
  • Understanding Sandbox, Workprofile and Userprofile

Hello,
I'm new to the GrapheneOS and I've read a lot about Sandbox, Workprofile and Userprofile but I don't understand it completely. Maybe someone can explain it to me like I'm stupid. I need to install GSF for banking and whatsapp (I mainly use Signal, but not all of my contacts do).
If I put an apple (Whatsapp) in a bowl (sandbox) and put that bowl next to the other bowls with everything else (other apps, system) in my kitchen, or I put it in an other room (with a Workprofile, e.g. Shelter app), or I put it in another house (Userprofile), what difference does it make? The apple will never see outside the bowl, aka Whatsapp/GSF should never see someting other than itself?
What point do I miss?
Thanks, Andy

Hi. I like your analogies.

  1. In order to run apps from Google Play store you need to install 3 components (play store, Play services, and framework). But GOS puts these google apples into a bowl (sandboxed Google play) just like aaaany other apple (app). Unlike stock android, GOS treats the Google apples like regular apples with no special place on the counter (privileges). You can deny them network access and as such cut them from the mother ship, for example. Impossible on stock android.

  2. There is a thing called inter process communication, short IPC. IPC is like a trail of ants which runs between the bowls of apples. They transport a certain amount of apple pieces between the bowls but you can't really know how much. In other words, even though the Google apps are treated like any other app they can communicate through IPC. As far as I know (which is really not that much) it's unlikely that they shovel huge chunks of data around. But you can circumvent this by using different rooms (profiles). Also, when you put your really sensitive data in a different user profile other than owner, your data is at rest and as such encrypted until you log in to that profile. The owner profile is the default profile that you use when booting the phone so your data is basically never at rest while your phone is running and your logged in.

Hope that helps a tiny bit. Welcome to GOS!

    • [deleted]

    Phead Re: 2
    Those may be different rooms, but they are still in the same house (device) and therefore may share same linkable characteristics (location, connection, hardware) which could be possibly accessed (IPC), exported, analyzed (server side) and linked. Not always WHAT but WHO WITH, WHEN and under what circumstances is important. Just a food for thought before you start putting bowls all over your house.

    Phead You're incorrectly implying that sandboxed Google Play has some special ability to communicate with other apps. They do not have any special privileges. That includes no special ability to communicate.

    even though the Google apps are treated like any other app they can communicate through IPC

    Apps within the same profile can communicate with mutual consent between the apps. For example, if you give the Contacts permission to one app, it could share access with another app within the same profile. It's supposed to enforce that the other app has the Contacts permission too but it may have a vulnerability or may ignore the permission model for nefarious reasons. This applies to any data you enter into apps and any form of access you grant including permissions. It is not something unique to Android. If you give data or access to software, it can do anything it's permitted to do with that data.

    People often try to use the Network toggle as a way to toggle off data exfiltration but it's not the intended purpose. Apps could exfiltrate data by sharing it with other apps, either via intents (IPC) or access to shared resources. They could also do something like playing audio at a supersonic frequency since there's no permission for playing audio. Network toggle is a toggle for the app directly using the network itself or indirectly using it via APIs requiring Android's INTERNET permission such as DownloadManager or another service provided by a user installed app. As with any other permissions, an app could choose not to enforce the standard permission model, which is part of what you trust them to do when you trust them with access. In the case of the Network permission, it's not always clear when apps should require it such as browsers not requiring it for apps opening a link. This is already addressed by the option to use multiple profiles and GrapheneOS also intends to provide app communication controls within profiles eventually but it's quite difficult and has major caveats since users granting other forms of shared access would bypass it, such as granting 2 apps the Contacts permission or access to a shared file.

      GrapheneOS

      Thanks for your correction! I did not mean to imply anything of that kind, really, though. I was trying to break down the technicalities of IPC as I grasp it. But you're right, I focused too much on google apps in particular.

      However, I have a question concerning your first paragraph: If I allow App A access to my contacts, it is free to share this permission (or data?) with any other within in the same profile (even though App B-D may not have access to my contacts)? It's obvious that whatever data I feed into App A is consumed by it one way or another. But making this data available to other Apps is a whole new concept to me. I haven't thought about that. Why is this possible? In my naive world I thought of app permissions to be more like usergroups on linux: App A belongs to group 5, App B to group 6. Group 6 has no RWX-Access to folders/files that belong to other groups and cannot access files created by App A. App A has to purposefully grant access to App B. Is that what you mean by

      It's supposed to enforce that the other app has the Contacts permission too but it may have a vulnerability or may ignore the permission model for nefarious reasons.
      ?

      • de0u replied to this.

        Phead In my naive world I thought of app permissions to be more like usergroups on linux: App A belongs to group 5, App B to group 6. Group 6 has no RWX-Access to folders/files that belong to other groups and cannot access files created by App A. App A has to purposefully grant access to App B.

        On Linux if App A and App B choose to communicate information via sockets, the file permissions for where they store the dara do not result in containment. Or any other channel, e.g., shared memory. Containment is hard.

          de0u

          Well, silly me who puts trust in file permissions.