Bug 1240604
Summary: | SELinux is preventing /usr/bin/abrt-action-generate-core-backtrace from 'read' accesses on the file /var/lib/mock/fedora-rawhide-x86_64/root/usr/bin/ruby-mri. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Vít Ondruch <vondruch> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | dominick.grift, dwalsh, jfilak, kibokin, lvrabec, mgrepl, plautrba |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | abrt_hash:0d4b16fec1fe238c628f34fb2fb8a61368b1120a7b046f5c20704c0a55364440 | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-07-19 15:14:25 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Vít Ondruch
2015-07-07 10:48:33 UTC
Probably best if abrt did not look at mock content. Might want to add a dontaudit rule for abrt to not look at unlabeled_t content. (In reply to Daniel Walsh from comment #1) > Probably best if abrt did not look at mock content. Actually there was an idea, that ABRT would report crashes inside mock the same way as it does for regular system and I like this idea, but not sure how far it is ... Jakub? It should work. ABRT should be able to report crashes inside a changed root environment or a container : https://github.com/abrt/abrt/wiki/Containers-and-chroots Since we do not know what content is in this build pool, for a security point of view, I would not want abrtd reporting on the content. (In reply to Daniel Walsh from comment #4) > Since we do not know what content is in this build pool, for a security > point of view, I would not want abrtd reporting on the content. Would you mind to explain a bit more? We know that the Ruby installed in Mock is coming from RPM, why should not ABRT report issue when the Ruby fails for some reason? I can't imagine that report from the mock chroot should be more insecure then report from my computer directly. Or is that the chroot content is not tagged "correctly" for some reasons, where my system supposedly is? (In reply to Daniel Walsh from comment #4) > Since we do not know what content is in this build pool, for a security > point of view, I would not want abrtd reporting on the content. I agree that accessing data in a changed root environment is not safe (because of mount namespaces created by regular users), but I do think that experienced users like Vít should be allowed to configure ABRT to detect and report such crashes (the same apply for autonomous build and test machines). ABRT makes copies of several files from the crashing process's root, so is there any other security issue than disclosing a private information? If there is no other issue, then I can assure you that the disclosure will not be possible too because ABRT will create a report accessible only to root. Description of problem: The Application is the 3D multiplayer video game "ARK: Survival Evolved" running on Valves Steam for Linux. ARK starts up fine, but when connecting to a server and loading a map, ARK crashes to the desktop and the SELinux notification shows up. Version-Release number of selected component: selinux-policy-3.13.1-128.10.fc22.noarch Additional info: reporter: libreport-2.6.2 hashmarkername: setroubleshoot kernel: 4.1.5-200.fc22.x86_64 type: libreport Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |