question about the use case for profiles

b3_k1nd_rw1nd

So, Dabbled with profiles and installing the google apps in them and seeing what happens. Something I realize I don't quite understand is the language around the use case for this.

I found this answer which seems to be the most layman explanation of why a person would use multiple profiles: https://discuss.grapheneos.org/d/301-why-two-profiles/2

If you don't have a reason to use multiple profiles, don't use them, GOS sandboxing and security mitigations still apply.
One may have concerns about inter-process communication between apps and Play Services and using multiple profiles mitigates that. But if you don't have a specific reason like "I don't want app X to be able to communicate with Google servers because Y", then it doesn't make sense to create multiple profiles just to isolate Play Services

And I just want to make sure I understand it correctly. If you have 2 apps installed and they both (let's say) require access to your contacts data but you don't want them sharing data between each other, then you can put them in separate profiles in order to make sure there's no inter-app communication? But this is not relevant I assume if you have 3 apps installed but none of them use the same permission, One of them uses calendar, one uses network and one uses notification. I assume in that case, there is no need to be concerned about inter-app communication since they are not accessing the same data? Or I have completely misunderstood the language around inter-app communication?

unwat

Yes, you're right. It's called IPC (inter-process communication). IPC can be set up and used only if there's mutual consent.

Like, programmer for app A needs to say "app A is going to send this specific message with this specific data to app B" and the programmer for app B needs to say "app B will accept this specific message with this specific data from app A." Two apps can send multiple and different kinds of messages to each other, but that requires lots of coordination for it to even work correctly.

So, a malicious app cannot send data around to other random apps. IPC is only used to improve functionality.

It's true apps could theoretically communicate with each other using storage permissions, etc. but you can protect yourself from this by restricting apps' permissions to what they actually need and by using storage scopes correctly, and adding full access to files/folders via storage scopes only when necessary.

Advice I've seen on Matrix and on here, and advice I follow, is to use profiles like you're using a completely different phone for whatever reason like work, personal, spycraft, etc., not to further isolate apps from each other. The app sandbox is enough to keep apps isolated from each other.

b3_k1nd_rw1nd

unwat So the way you are describing it makes it seem more like this IPC is via direct communication and not via permissions we give them via the Permissions page.....But I assume for that sort of IPC, both apps have to be engaged in that for it to work.

So, if say, hypothetically, I had 5 apps, 4 don't have the logic for IPC, but the 5th tries to coordinate with them and get their data. If the other apps don't have the logic to talk to it, then it can't get their data another way, I assume? Besides the storage permissions logic which you have already illustrated can be blocked with properly setup storage scopes?

b3_k1nd_rw1nd

unwat The app sandbox is enough to keep apps isolated from each other.

So, even if I don't use a separate profile, and everything is on the same profile, the apps are still isolated with their own app sandbox? Then is the worry that the sandbox is not perfect and that's where different profiles become useful? When would sandbox not be a sufficient level of compartmentalization?

unwat

Right. IPC is not something that can be controlled in permissions. It's just something that Android apps can do.

Also, yes, your example about the 5 apps is correct. App 5 simply cannot communicate with apps 1-4.

I don't know how to answer the other questions briefly...

The truth is there are ways to communicate out of the sandbox, mostly by exploiting permissions apps have (like storage, microphone, sensors, or internet). Any permission granted increases attack surface. In practice, the sandbox and restricting apps' permissions to only what they actually need is all you need to do. An app with no permissions has no way to communicate out of the sandbox. Being smart with permissions makes these ways infeasible to impossible.

For general use, the sandbox is sufficient. Using a web app is even better because there would be two sandboxes (and no permissions to worry about). Companies like Facebook wouldn't bother trying to get around the sandbox. They won't try to get access to what they can't access easily. There are tons of easier targets, like people who willingly give access to everything.

Profiles aren't necessary to further sandbox anything. The only real difference is no inter-profile IPC and apps can't see what apps are installed in other profiles. They're primarily used as separate "workspaces," like I mentioned in my last post, but if someone wanted to be extra careful, they could use profiles if they wanted. The best way would be to have nothing installed on the owner profile, then use other profiles one at a time (not leaving multiple running at the same time). This way it's almost like having different phones. It would be completely impossible for apps to communicate with each other considering any hypothetical, impractical, or whatever methods. It's not necessary to put so much effort into this, but it all depends on a person's threat model.

It would probably be helpful to read pretty much everything on GrapheneOS's features page. Each of those features, including security features, aren't included in Stock Android. Other than further hardening the sandbox, GOS does much more to keep us secure.

b3_k1nd_rw1nd

unwat This is incredibly helpful. Thank you :)

It would probably be helpful to read pretty much everything on GrapheneOS's features page.

I have :-( , those pages are not ELI5 level language. And I am saying that as someone from a technical background.

But one thing I am surprised about is you saying this

Using a web app is even better because there would be two sandboxes (and no permissions to worry about).

The sentiment I have come across online is using a web browser on your phone, while convenient is actually not the best cause it can lead to web exploits running on your phone and that's a whole other can of worms. You disagree with that? or I am misunderstanding you?

Also

Companies like Facebook wouldn't bother trying to get around the sandbox. They won't try to get access to what they can't access easily.

Really? Guess it's a difference of opinion but I would be surprised if Facebook, which is first and foremost a data hoarder wouldn't bother getting around restrictions that limit how much data they can get from you. Agree to disagree I guess?

unwat

b3_k1nd_rw1nd using a web browser on your phone, while convenient is actually not the best cause it can lead to web exploits running on your phone and that's a whole other can of worms

I guess it depends on what data an adversary is trying to access. On one hand, if a malicious site is trying to access data on the phone, using the browser is more secure because the browser has its sandbox that isolates the site, then the browser is also isolated in its app sandbox. In effect, there are two barriers to get past.

On the other hand, if you're talking about comparing Android's app sandbox vs Chromium's site sandbox, then I have no idea. They're both sufficient and they're both vetted and tested by Google and security experts around the world. Additionally, GrapheneOS's secure app spawning helps defeat/prevent the most common forms of exploits. All of what GrapheneOS's hardened memory allocator does is covered here. If you look at the CVEs listed in this document (one that's linked to from the GrapheneOS website), you'd find most vulnerabilities are caused by memory issues. If an app runs into a memory issue on GrapheneOS, it usually just crashes.

Considering how secure Linux and Android already are, paired with the added hardening the GrapheneOS team does, any remaining hypothetical vulnerabilities would be extremely rare and access to data would be very limited in scope, thanks to the app/site sandboxes.

b3_k1nd_rw1nd Agree to disagree I guess?

Sure. I guess the way I see it is people who are knowledgeable about security and privacy will take steps to restrict data-hungry companies, but we're just a very small subset of the population. Like, I think big companies like Facebook would rather spend their money finding ways to keep billions of users on their site than to spend money on finding short-lived exploits to get data on just a few hundred thousand people.