Bug 1142976

Summary: Please allow abrtd to read /dev/mem
Product: Red Hat Enterprise Linux 7 Reporter: Jakub Filak <jfilak>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Dalibor Pospíšil <dapospis>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.1CC: dapospis, jberan, jfilak, mmalik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.13.1-3.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1210598 (view as bug list) Environment:
Last Closed: 2015-03-05 10:41:07 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:    
Bug Blocks: 1139552    

Description Jakub Filak 2014-09-17 16:41:30 UTC
Description of problem:
ABRT needs to generate an unique machine_id and we want to use sosuploader's algorithm based off dmidecode[1] fields. I've developed a simple python script [2] generating the machine_id and configured abrtd to run this script. Unfortunately, abrtd seems to be disallowed to read /dev/mem.

If I run 'semodule -DB', I get the following AVC:

type=SYSCALL msg=audit(1410968097.477:1051): arch=c000003e syscall=2 success=yes exit=11 a0=7f0cbda635e0 a1=0 a2=0 a3=8 items=0 ppid=22396 pid=22411 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrt-action-gen" exe="/usr/bin/python2.7" subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1410968097.477:1051): avc:  denied  { sys_rawio } for  pid=22411 comm="abrt-action-gen" capability=17  scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tclass=capability
type=AVC msg=audit(1410968097.477:1051): avc:  denied  { open } for  pid=22411 comm="abrt-action-gen" path="/dev/mem" dev="devtmpfs" ino=4482 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file
type=AVC msg=audit(1410968097.477:1051): avc:  denied  { read } for  pid=22411 comm="abrt-action-gen" name="mem" dev="devtmpfs" ino=4482 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file

and adit2allow says:
#============= abrt_t ==============
#!!!! This avc has a dontaudit rule in the current policy
allow abrt_t memory_device_t:chr_file { read open };
#!!!! This avc has a dontaudit rule in the current policy
allow abrt_t self:capability sys_rawio;


Version-Release number of selected component (if applicable):
selinux-policy-3.12.1-153.el7_0.10.noarch


1: http://www.nongnu.org/dmidecode/
2: https://fedorahosted.org/python-dmidecode/

Comment 2 Miroslav Grepl 2014-10-02 10:55:51 UTC
Author: Miroslav Grepl <mgrepl>
Date:   Thu Oct 2 12:54:57 2014 +0200

    Allow abrt to read /dev/mem to generate an unique machine_id and uses  sosuploader's algorithm based off dmidecode[1] fields.

Comment 4 Dalibor Pospíšil 2014-11-10 14:15:24 UTC
Could you, please, provide the exact steps how to reproduce this issue? Particularly how to configure abrt to execute the script?

Comment 5 Jakub Filak 2014-11-13 10:51:04 UTC
Sure! Here you go:

1. make sure ABRT is configured to include 'machineid' file in dump directories (default in abrt-2.1.11-17.el7)

  /etc/libreport/events.d/abrt_event.conf

  ...
  EVENT=post-create
    /usr/libexec/abrt-action-generate-machine-id -o $DUMP_DIR/machineid >>event_log 2>&1 || :
  ...

2. generate a crash (e.g. run will_segfault (will-crash package from EPEL7))

3. cd /var/tmp/abrt/$problem_dir && cat machineid | grep sosreport_uploader-dmidecode

4. sudo /usr/libexec/abrt-action-generate-machine-id -g sosreport_uploader-dmidecode

5. results of the 3rd step and the 4th step are equal

Upstream test case: https://github.com/abrt/abrt/tree/master/tests/runtests/distro_specific/rhel7/ureport-machineid

Comment 10 errata-xmlrpc 2015-03-05 10:41:07 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0458.html