Geoclue2 local user security model

I’m currently looking into geoclue2 and try to understand what the local user security model is.

There are agents and applications that are “whitelisted” via /etc/geoclue2/geoclue.conf. These whitelistings work via string identifiers that are provided by the to-be-whitelisted parties, however. Both agents and applications run in the context of possibly unprivileged users, maybe even nobody. The agent is seemingly also supposed to control which application may access geo location.

It looks like it is a kind of cooperative approach where each component is trusted to behave correctly. But I can’t see how this protects against malicious actors in the system. Like a compromised nobody user account might be able to obtain location information that it otherwise maybe could not get with this level of precision.

I’d be happy about additional design insight in this area.

Thanks!

CC @zeenix to check that my answer is correct

Any process that can talk to geoclue is trusted to not be evil. It has to be: consider that a sandboxed process won’t be able to talk to geoclue without a sandbox hole, whereas an unsandboxed process can simply do anything that geoclue could do itself (well, except stuff that requires the permissions of the geoclue user, but I suspect nothing does?), so ability to talk to geoclue does not really matter for security purposes. Hardening geoclue to not trust processes that have access to the system bus would be pointless, since such processes are unsandboxed and can read your entire home directory, enumerate your password manager, upload everything to Russia, etc. etc.

Special privilege is not required to accurately identify the user’s location. You don’t need it to get the user’s IP address. You don’t need it to look at nearby Wi-Fi networks: NetworkManager will happily enumerate those for you. So locking down geoclue in an attempt to prevent applications from using it to geolocate doesn’t achieve much. Thus, the permissions are designed to constrain sandboxed applications, which do not have access to the system bus and which are intermediated by the geolocation portal (of xdg-desktop-portal). The only way for an untrusted process to talk to geoclue is to go via the geolocation portal, which can apply real permissions and really stop apps from geolocating you. (Sans bugs.)

Like a compromised nobody user account might be able to obtain location information that it otherwise maybe could not get with this level of precision.

I don’t think so, because the permissions of the nobody user to access system resources should be equivalent to any other unprivileged user, right? This only matters to the extent that the geoclue user actually has extra special permissions above and beyond a standard user. I doubt it does.

Thanks for your reply!

whereas an unsandboxed process can simply do anything that geoclue could do itself (well, except stuff that requires the permissions of the geoclue user, but I suspect nothing does?),

At least there exist polkit rules 50-org.freedesktop.GeoClue2.rules that grant the geoclue user access to ModemManager D-Bus functions for controlling the device and obtaining the location.

Hardening geoclue to not trust processes that have access to the system bus would be pointless, since such processes are unsandboxed and can read your entire home directory, enumerate your password manager, upload everything to Russia, etc. etc.

I only partly agree. Yes untrusted processes typically have access to the network and can upload data to remote systems. Reading entire home directories might be possible by default in certain distributions but it is not really recommended these days any more to have 0755 permissions on home directories. And having access to the system bus does not imply having access to everything that is going on there, most services running on the system bus employ authorization checks based on Polkit to e.g. differentiate processes of users in an active local session from other users. Many operations also require root authentication.

I don’t think so, because the permissions of the nobody user to access system resources should be equivalent to any other unprivileged user, right? This only matters to the extent that the geoclue user actually has extra special permissions above and beyond a standard user. I doubt it does.

If the geoclue service has permissions to read more accurate location information (e.g. from ModemManager, see above) that otherwise is not available then nobody would at least get that additional information for free.

OK, interesting!

You’re going to have read access to your home directory, though. And with access to the session bus as well, you definitely have full control over anything going on there. Once you have user privileges, I think the game is fully over (unless this is a rare case of a multi-user system, in which case other users are fine).

OK, makes sense.

You’re going to have read access to your home directory, though. And with access to the session bus as well, you definitely have full control over anything going on there. Once you have user privileges, I think the game is fully over (unless this is a rare case of a multi-user system, in which case other users are fine).

For multi user systems, yes. I am more worried about another scenario though. A minor service user being compromised (like nobody, which serves only as an example here, since it has less and less uses these days) could allow the attacker so get to know the exact location of the compromised host (if sufficiently accurate sources like a GPS device are available).

If the host should happen to be a mobile device then that information could be even more sensitive.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.