Leaking from Private Space to Owner and Intent Verification Service?

looped_around

Finally looking closer at owner profile RethinkDNS + Wireguard proxy Logs and I see Amazon, Lyft, and other DNS entries allowed... I only installed play services + apps in Private space.
But I'm seeing these requests go out the wg3 proxy. I found they were all attached to the intent verification service.

Still new, don't be rude if I'm using incorrect terms. I have screenshots from Rethink but cannot find a way to attach.
Not sure what else to look for but please, how do I make this stop? And how can I tell if it was just a DNS request or traffic? What's the chance more than DNS leaked out of my private space out of my owner profile VPN?

blackrose

If I get your setup correctly, then this is expected.

Wireguard installed in your owner profile do not route the private space traffic through it.
Same for any DNS service.

You need to have them installed in your Private Space as well.

looped_around

blackrose

I can clarify. I don't want private space apps over VPN or into my owner profile. But they are showing up in the owner profile rethink and going out the owner profile VPN when not supposed to :(

looped_around

@admin i looked for open issues in case of workaround or solution but I didn't see one. I'm hoping to hear maybe I have a toggle done wrong somewhere?

other8026

Sounds like this is what's happening: https://grapheneos.org/usage#app-link-verification, though I don't know if this is done from the owner profile or the profile where the apps are installed.

looped_around

other8026
Yes, there's 2 of them and two intent resolvers, one pair in owner and one in private (and others in unique profiles).
But apps in private space shouldn't have access to use the owner profile intent verification.
Its crossing the private space border; leaking. This is my concern. If private space apps can access an owner space android app in lieu of the private space one, what else are they accessing?
For both, the app size is 0, but in owner the user data is 1.2M and in PrS it's 0. So the functionality is broken, or intentional; I don't believe it's intentional because unique apps from other profiles are not using the space.
Would you check that app on yours for user data size if you have similar disparities?

I need the app intent verification to work, for various scenarios. But the bigger concern is the sandbox didn't sandbox?
If you give me instructions I can pull more info also for admin to investigate? I hope I'm explaining better.
Thank you

Side: while the usage explains it's only a wget, when the app name is "Pizza Miami 5th St" (Functional) coming from a VPN IP, it makes a more unique inet fingerprint :(

looped_around

other8026
So I make a bug request?

other8026

looped_around Looking at old messages from GrapheneOS developers, they say that app link verification is a global thing, so it's the owner profile that does that. The message was from a while back, but I guess that hasn't changed.

alfred

looped_around It sounds like the Intent Filter Verification Service runs in the owner profile and is responsible for the traffic, and not the actual app. The apps themselves are not accessing the Intent Verification service, rather it sees which apps are installed and checks what links they have permission to use. If that makes sense.

It still sounds like a bug though.

I did a quick test and was able to replicate your results.

Owner Profile has Always On VPN, and blocks connections without VPN.
Private space has no VPN.
Install App in private space. (Tested with WhatsApp and Snapchat)
Launch app from private space.
DNS requests are leaked into the Owners VPN tunnel. Verified with a packet capture.

There is not a lot of data, so I think it is just the DNS and App link verification traffic.

You could possibly try turning off the VPN kill switch and see if that changes anything.

looped_around

alfred

Thank you for confirming and helping my explanation!
Did you happen to see if other profile apps with intent links were also populating? I hadn't but it might have been a timing thing for me. P6A is a bit limited.
I hadn't realized private DNS might prevent queries going through the appropriate tunnel also as it's global, so I will disable that and recheck, but I think this is because the intent check may be global.
The way you explained how it operates is very helpful for my understanding, I hadn't realized.

I think I imagined if it's global it would go the way of app Verification and updates, instead of out my VPN tunnel with other owner profile traffic.

soupslurpr

Is private DNS enabled (even set to automatic)?

"We strongly recommend fully disabling Private DNS when using a VPN on any secondary profile until it's overhauled."
https://grapheneos.org/faq#:~:text=We%20strongly%20recommend%20fully%20disabling%20Private%20DNS%20when%20using%20a%20VPN%20on%20any%20secondary%20profile%20until%20it%27s%20overhauled.

looped_around

soupslurpr
I appreciate the reminder of this, in private space it was set for automatic. I have to check the other profiles but I thought I disabled it.
If it's global tho enabling automatic on private space might have changed those. My private space has no VPN, so I was following their suggestion further up but forgot about the bit you highlighted. I will disable it then, I see now its on by default.
I'm going to check how that toggle impacts the other profiles out of curiosity tho, thank you.

alfred

soupslurpr Is private DNS enabled (even set to automatic)?

This still happens when private DNS is disabled. It looks like other8026 confirmed that is the expected behavior for now.

looped_around Did you happen to see if other profile apps with intent links were also populating?

It did for the couple apps I tested. Apparently, the app link verification will cache the results, so the web requests are not run every time you open the app. Not sure how long it is cached for.

logsmarter44 Disabling networking for the intent verification app seems possible and should stop the traffic. However, it would be wise to test this at the router level.

For anyone wondering, I did verify with a router packet capture that disabling network access for the Intent Filter Verification Service does indeed stop the network traffic.

looped_around

other8026
Thank you for finding that!
I considered that possibility, but I didn't see any secondary profile queries only private space, but perhaps it was a timing coincidence.
If global though, would that mean it should be treated like integrity checks and updates as opposed to going out the owner profiles VPN tunnel?

Thank you for sticking with me to understand this better and sorry about the delay. I may need to reimagine the owner profile using VPN if it will send wgets and DNS for Google installed apps out the tunnel. Before redesigning my setup I need to check that it doesn't just send it out the active profile.

other8026

looped_around The old messages that I found the developer sent in the group said that those checks go over the owner VPN.

logsmarter44

I noticed this a few months ago as well. Disabling networking for the intent verification app seems possible and should stop the traffic. However, it would be wise to test this at the router level. Don't rely solely on a userspace app like Rethink to accurately report networking activity for system apps. Verify it externally instead.

looped_around

logsmarter44
That would be my preference. My advanced router died and I'm using a cheap sub until I can source a new one that doesn't make me think it's useless. Building one gives me nightmares.