Bug 986844

Summary:	geolocation logging in anaconda.log compromises user's privacy
Product:	[Fedora] Fedora	Reporter:	Steve Tyler <stephent98>
Component:	anaconda	Assignee:	Martin Kolman <mkolman>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	dshea, g.kaviyarasu, jonathan, mkolman, sbueno, stephent98, vanmeeuwen+fedora
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	anaconda-20.10-1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-04-14 16:35:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Steve Tyler 2013-07-22 08:34:14 UTC

Description of problem:
With F19, anaconda.log records the user's territory and time zone as determined by the geolocation feature. When a bug report is submitted to bugzilla, this log is stored on the bugzilla server, where it is accessible to anyone. This compromises the user's privacy.

There is no reason for all logs to contain this information. For example, Bug 985207 has nothing to do with geolocation, yet the user's territory and time zone are there in anaconda.log for anyone to see.

Further, bug reports submitted from a VM contain the same geolocation information. The advantage of a VM is that it shields data on the host from being logged, but the geolocation logging compromises this advantage.

Version-Release number of selected component (if applicable):
anaconda 19.30.13-1

How reproducible:
Always.

Steps to Reproduce:
1. Generate an anaconda exception.
2. Submit a bug report to bugzilla.
3. Examine anaconda.log and anaconda-tb-*.

Actual results:
anaconda.log contains records like this (actual data obfuscated to protect the user's privacy):
...
20:01:09,707 INFO anaconda: Starting geolocation lookup
20:01:09,709 INFO anaconda: Geolocation provider: Fedora GeoIP
20:01:10,940 INFO anaconda: Geolocation lookup finished in 1.2 seconds
20:01:10,941 INFO anaconda: territory: XX
time zone: Yyyy/Zzzz (from GeoIP)
...

Expected results:
No explicit geolocation information is logged.

If the geolocation feature needs to log this personal information, it should be done with the user's knowledge and consent. For example, the user could be asked to enable geolocation logging for debugging purposes.

Additional info:

Comment 1 Steve Tyler 2013-08-26 18:41:16 UTC

(In reply to Steve Tyler from comment #0)
...
> If the geolocation feature needs to log this personal information, it should
> be done with the user's knowledge and consent. For example, the user could
> be asked to enable geolocation logging for debugging purposes.
...

For example, in Bug 1000715, the installer crashes when some languages are selected, but not when others are selected. If the language is determined by geolocation, it could be useful to know what geolocation was actually returned by the server.

See Bug 1000715, Comment 21 for a possible use-case where geolocation debugging would need to be enabled.

Comment 2 Martin Kolman 2013-08-26 19:15:13 UTC

I agree this should be fixed, as the territory & timezone info might be sensitive in some cases and can be easily leaked. Also Anaconda automatically saves the log file to the hard disk after installation, so it might be present on the installed system for quite some time.

So I agree it should be removed from the main (persistent) log.

Still, it is also a valid point that it might sometime be usable for debugging installation issues - one possible way of handling this is to have a separate "sensitive" log file (called for example "anaconda_sensitive_data.log", that would be used for storing possibly sensitive debug information and will be deleted (or more exactly not copied to the installed system) once the installation is finished. 
But the log would still be there during the installation and testers could manually provide it on their own discretion.

What do you think about this idea ? (should be probably a separate feature request)

Comment 3 Steve Tyler 2013-08-26 19:44:18 UTC

There are already several anaconda log files that need to be correlated when analyzing a bug, so adding another one wouldn't make that any easier, unfortunately.

I would propose a kernel command-line option to specifically enable geolocation debugging, for example "inst.geoloc_debug". That is not especially convenient, I admit, but it would allow geolocation logging to be seen in the context of other logging in anaconda.log. That would also follow the precedent of many other debugging options.[1]

You are right that sensitive information in the log file would be copied to the target system, but it would be done with the user's knowledge and consent, because someone, such as a developer, would have asked the user to enable geolocation debugging.

[1] Examples of anaconda and kernel debugging options:

Snippets from anaconda-20.8-1/docs/boot-options.txt:
...
:dracutdebug:  {dracutdoc}#_troubleshooting[dracut "Troubleshooting" guide]
...
`inst.loglevel=<debug|info|warning|error|critical>`::
...
Use `inst.debug=1` to add a "debug" button to the UI, which allows dropping
...

Snippets from /usr/share/doc/kernel-doc-3.10.9/Documentation/kernel-parameters.txt:
...
        acpi.debug_layer=       [HW,ACPI,ACPI_DEBUG]
        acpi.debug_level=       [HW,ACPI,ACPI_DEBUG]
...
        bootmem_debug   [KNL] Enable bootmem allocator debug messages.
...
        ddebug_query=   [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
...
        debug_objects   [KNL] Enable object debugging
...
Etc.

Comment 4 Martin Kolman 2014-04-14 16:35:49 UTC

Fixed in F20, closing.