forbidden words does not match design, sensitive data is leaked

[genodeftest]

Currently libreport does not stop words like the real username or paths in /home/username/, UID, etc. from being leaked. According to the design document [1] this information should be removed:

• User's real name
• usernames
• email addresses
• social security numbers
• phone numbers
• IP addresses
• Document titles
• user filenames (especially in $HOME)
• URLs

Some of this is quite hard to accomplish, but it would be a good point to start with not leaking username, paths in /home/username or $HOME, UID, hostname and some other simple things.

[1] https://wiki.gnome.org/Design/OS/ProblemReporting#Guidelines

[jfilak]

I do pay attention to your findings, but unfortunately I need to know where exactly libreport leaks that information in order to be able to fix it. Could you please provide me with links to the affected bug reports here or send me them via email (or via any service of your choice).

[genodeftest]

Take for example the bug report https://bugzilla.redhat.com/show_bug.cgi?id=1205451 and its attachments. Look into the file "environ". You will find several paths under /home, the username, hostname, UID, etc. The files "maps" and "open_fds" sometimes contain local folders under /home "mountinfo" contains some user-specific information, e.g. filesystems mounted by gvfs

In https://bugzilla.redhat.com/show_bug.cgi?id=1188619 you can e.g. see the uid.

In https://bugzilla.redhat.com/show_bug.cgi?id=1218372 , attachment "File: var_log_messages" contains the hostname and UID

In https://bugzilla.redhat.com/show_bug.cgi?id=1205449 attachment "File: dmesg" containts the hostname

Sometimes e.g. the cmdline field containts a local path as in https://bugzilla.redhat.com/show_bug.cgi?id=1203027

I think you got the point. Is there a simple way to exclude those files and fields from the bug report? In most cases you don't need more than just the "backtrace" file anyway.

[jfilak]

Ooh, it seems that we've completely failed in communication with our users. Of course, there is a simple way to exclude those files. Just un-check the unwanted files on the review page before you check "I reviewed the data and agree with submitting it" check box and click the "Next" button (double click opens the selected file for writing) (it wouldn't be a bad idea to mention that you have excluded some files from the report in the comment as the maintainers might blame libreport for not attaching that data). On the previous page, you can search for arbitrary strings in the problem data and you can remove the unwanted strings from the files. If you want to exclude some files from all reports, put the file names on the list of "AlwaysExcludedElements" (man libreport.conf).

[genodeftest]

If you do so (exlude some of these files) the server (at least at Red Hat) won't accept the report any more.

This is about the defaults, this is not about choices a user has when editing files.

[jfilak]

Yes, some of the files are required to detect Bugzilla product and component and others fields (os_info, component, etc.), but I am pretty sure Red Hat Bugzilla does not refuse to open a bug report because of missing attachments. You can help us by providing the list of the files you wanted to exclude but you could not do that because the files were required for filing a bug in Red Hat Bugzilla.

The defaults are configured to provide as much information as possible. You can add the files you don't want to share with maintainers to the list of always excluded files (search for AlwaysExcludedElements in man libreport.conf). You can also configure libreport to always mark Red Hat Bugzilla bugs private [1].

1: http://abrt.readthedocs.org/en/latest/faq.html#how-do-i-create-a-private-bugzilla-ticket

[genodeftest]

I read and understood that. Still I think the default should be to not leak this information. I know the configuration option is there, but it is about the defaults.

Red hat bugzilla responds with a 502 if no environ file is given.

[sorki]

I regularly report bugs without environ attached because it contains a lot of mess. So it's definitely possible and there's no mechanism that would require environ attachment. 502 error is probably not related to this.

[jfilak]

We should replace UID with these tokens - root (UID==0), system (UID < 1000), user.

[jfilak]

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1169760