Bug 1009730

Summary:	'Sensitive' information logic too dumb to be much use
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	libreport	Assignee:	Jakub Filak <jfilak>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	dvlasenk, jberan, jfilak, jmoskovc, kparal, kvolny, mcatanzaro+wrong-account-do-not-cc, mlichvar, mmilata, mtoman, pedrogfrancisco
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	libreport-2.1.10-1.fc21	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-01-08 06:52:05 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 Adam Williamson 2013-09-19 02:29:32 UTC

libreport's handling of 'sensitive' information in reports is a good idea, but the current implementation is kinda useless in practice.

There's a couple of major problems:

i) It has a fairly generous definition of 'possibly sensitive'
ii) It doesn't distinguish between different types of potentially-sensitive information at all

So in practice, almost every single report you ever submit has the 'possibly contains sensitive data!' stuff come up, which trains you in short order to ignore it, which means when you hit a report which *really does* have your password in plain text, you've been trained to click straight through and you go ahead and post it on Bugzilla. This has actually happened to real people, more than once.

Specific details on i): for instance, every single crash I've submitted in the last few months has had my username in the 'environ' data, and this is flagged as sensitive. libsecret.so is very frequently loaded, and the string 'secret' is flagged.

Either we need to get more strict about the flagging, and maybe 'whitelist' things that are _always_ there or just drop the username from the data (is it really any use to anyone?), or implement some kind of concept of 'sensitivity levels', or probably both. I can see it being a much better system if we don't submit your username in just about every report, and something that looks like a password sets off much more serious alarms than something that looks like a username.

Comment 1 Adam Williamson 2013-09-19 02:29:57 UTC

this may be gnome-abrt not libreport; please re-assign if so. I don't know where the 'sensitive data' stuff is handled.

Comment 2 Jiri Moskovcak 2013-09-19 21:15:11 UTC

So I've implemented the whitelist, so far I have this words:

login.so  #rhbz#896246
libsecret.so

Do you have any other candidates for this list?

Comment 3 Adam Williamson 2013-09-19 23:10:21 UTC

As mentioned above, the 'environ' tab of the 'sensitive data' dialog always/almost always highlights the line:

USERNAME=adamw

amusingly, the line:

USER=adamw

right before it is *not* highlighted. Outright *suppressing* that may be better than whitelisting it, though, I suppose.

Comment 4 Jiri Moskovcak 2013-09-20 06:13:14 UTC

Filtering the saved information will require more code changes, so for now I'm going to put it to the whitelist (and hope, that noone considers their username as sensitive information).

Comment 5 Adam Williamson 2013-09-20 06:54:08 UTC

well if you're going to take that approach you may as well just take 'username' out of the list of strings that trigger the 'sensitive info' path, rather than listing it in both the blacklist *and* the whitelist :)

Comment 6 Nicolas Mailhot 2013-09-20 08:15:59 UTC

Also:
SHELL=/sbin/nologin/

Comment 7 Jiri Moskovcak 2013-09-23 08:30:46 UTC

commit 6fcea5a51c4a25d8d756dde6f15bee8aee11585e
Author: Jiri Moskovcak <jmoskovc>
Date:   Fri Sep 20 14:44:35 2013 +0200

    added whitelist for sensitive data - rhbz#1009730 rhbz#896246
    
    
    Signed-off-by: Jiri Moskovcak <jmoskovc>

Comment 8 Kamil Páral 2013-09-25 11:42:23 UTC

More lines to filter out:

... /lib64/libsystemd-login.so.0
... /lib64/libaccountsservice.so.0
... /usr/lib64/girepository-1.0/AccountsService-1.0.typelib

Comment 9 Jiri Moskovcak 2013-09-27 11:26:29 UTC

*** Bug 896246 has been marked as a duplicate of this bug. ***

Comment 10 Michael Catanzaro 2013-10-25 01:28:59 UTC

The other major usability issue is that although possibly sensitive text is highlighted, you usually have to horizontal scroll in order to see it, which is not practical in combination with the required vertical scrolling: you'd have to spend ages doing some sort of checkerboard pattern to inspect all the data and ensure you haven't missed anything highlighted.

Ideally there would be a quick way to jump between highlighted terms, but simply removing horizontal scrolling would help a ton.

Comment 11 Adam Williamson 2013-10-25 01:54:54 UTC

"Ideally there would be a quick way to jump between highlighted terms"

There actually is one - I forget the details, but there is a button somewhere in the window which simply jumps from highlighted term to highlighted term. I missed it for a while too, but once I found it it looked pretty obvious.

Comment 12 Jakub Filak 2013-10-25 07:34:46 UTC

(In reply to Adam Williamson from comment #11)
> "Ideally there would be a quick way to jump between highlighted terms"
> 
> There actually is one - I forget the details, but there is a button
> somewhere in the window 

The hidden jump buttons are located on the right bottom corner of the window right after the search text entry.

http://jfilak.fedorapeople.org/media/report-gtk-highlight-sensitive-buttons.png

Comment 13 Michael Catanzaro 2013-10-25 13:02:07 UTC

Oh that's good.  It really ought to be much clearer, though.

Comment 14 Adam Williamson 2013-12-04 01:20:37 UTC

'accountsservice' in various forms (it's a GNOME lib) is still a problem in current F20. and yeah, it'd be nice to make the 'jump to next sensitive item' arrows a LOT more obvious somehow.

Comment 15 Jakub Filak 2013-12-06 16:24:03 UTC

I've created a pull request [1] which adds 'accountsservice' to the sensitive white list.

1: https://github.com/abrt/libreport/pull/221

Comment 16 Jakub Filak 2013-12-11 11:00:35 UTC

Upstream commit ffcca2e498bfbf761c8398a82c15e2b4dd1a6043 fixes this bug.