Bug 1214175

+++ This bug was initially created as a clone of Bug #1128400 +++

Description of problem:
Kerneloops handlers can be called by any user by communicating directly with the journal unix socket and setting the analyzer as Kerneloops. When this analyzer is set then dmesg is called and dumped to the output dump directory. The dump file is given the permissions of the calling user, which allows any user to read dmesg.

The problem is that no appropriate checks or privilege dropping is done before calling dmesg.

How reproducible:
As long as bug is not duplicate (change type), always when the script is ran from any user.


Steps to Reproduce:
1. Set dmesg_restrict
2. Run attached Python script
3. Navigate to dump directory
4. View dmesg

Actual results:
$ cat /proc/sys/kernel/dmesg_restrict 
1

$ dmesg 
dmesg: read kernel buffer failed: Operation not permitted

$ cat /dev/kmsg 
cat: /dev/kmsg: Operation not permitted

$ python kerneloops.py

$ stat /var/tmp/abrt/dumpit-2014-08-09-23\:02\:36-1/dmesg 
..
Access: (0660/-rw-rw----)  Uid: ( 1001/ test)   Gid: (  173/    abrt)
...

Expected results:
Don't dump dmesg if calling user is restricted.

--- Additional comment from Murray McAllister on 2014-08-12 07:24:23 CEST ---

Hello,

Thank you for the report! I am going to get one of our kernel people to check this, whether it should be treated as a security flaw or just hardening.

Thanks,

--
Murray McAllister / Red Hat Product Security

--- Additional comment from Jakub Filak on 2014-11-11 10:29:53 CET ---

(In reply to Murray McAllister from comment #1)
Murray, any update on this bug report?

Should ABRT stop saving dmesg in the problem directories? Or should ABRT make the problem data accessible to root only if /proc/sys/kernel/dmesg_restrict is 1?

I prefer the latter option.

--- Additional comment from Murray McAllister on 2014-12-18 03:45:46 CET ---

Apologies for missing this and the long delay. From our kernel person:

"this could be treated more as a hardening issue than a security one. More so, it needs to be fixed on the abrtd side, as it provides the journal socket access to user applications to write log messages. without it, the reproducer does not work."

--- Additional comment from Murray McAllister on 2014-12-18 03:47:51 CET ---

I have asked someone to provide guidance on the question.

--- Additional comment from Josh Bressers on 2015-03-31 19:50:12 CEST ---

I'm removing the security flag from this bug. Fedora should not have embargoed issues and this should be opened up so it can be fixed.

--- Additional comment from  on 2015-04-17 18:08:50 CEST ---

With all of the new abrt issues going on around and other 'information disclosure' ones coming out, I figured I should update this ticket so it's in the list.