Bug 1128400
| Summary: | ABRT does not honor dmesg_restrict | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | tborland1 | ||||
| Component: | abrt | Assignee: | abrt <abrt-devel-list> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 21 | CC: | bressers, fweimer, jfilak, security-response-team | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | gnome-abrt-1.2.0-1.fc22 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1214175 (view as bug list) | Environment: | |||||
| Last Closed: | 2015-06-21 00:33:34 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: | |||||||
| Bug Depends On: | 1227661 | ||||||
| Bug Blocks: | 1214172, 1214175 | ||||||
| Attachments: |
|
||||||
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 (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. 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." I have asked someone to provide guidance on the question. 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. 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. This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Still present in Fedora 21 at least. gnome-abrt-1.2.0-1.fc22,abrt-2.6.0-1.fc22,libreport-2.6.0-1.fc22,satyr-0.18-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/gnome-abrt-1.2.0-1.fc22,abrt-2.6.0-1.fc22,libreport-2.6.0-1.fc22,satyr-0.18-1.fc22 Upstream commit https://github.com/abrt/abrt/commit/45975f6b8d6940865b67f63b99a062b5ecbb217b fixes this bug. Package gnome-abrt-1.2.0-1.fc22, abrt-2.6.0-1.fc22, libreport-2.6.0-1.fc22, satyr-0.18-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-abrt-1.2.0-1.fc22 abrt-2.6.0-1.fc22 libreport-2.6.0-1.fc22 satyr-0.18-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-9886/gnome-abrt-1.2.0-1.fc22,abrt-2.6.0-1.fc22,libreport-2.6.0-1.fc22,satyr-0.18-1.fc22 then log in and leave karma (feedback). gnome-abrt-1.2.0-1.fc22, abrt-2.6.0-1.fc22, libreport-2.6.0-1.fc22, satyr-0.18-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 925466 [details] trigger Kerneloops from any user 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.