Bug 1411331 - abrt-harvest-vmcore can't read the kernel crash
Summary: abrt-harvest-vmcore can't read the kernel crash
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-09 13:53 UTC by Frank Büttner
Modified: 2020-06-29 05:15 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-12 12:17:45 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Frank Büttner 2017-01-09 13:53:36 UTC
Description of problem:
When the kernel was crashed after the reboot abrt-harvest-vmcore can't  read the crash.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.13.1-102.el7_3.7.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Let the kernel crash
2. wait for reboot


Actual results:
At the reboot abrt-harvest-vmcore can't read the crash dump directory.

Expected results:
abrt-harvest-vmcore can analyse the crash.


Additional info:
systemd:
abrt-harvest-vmcore[2383]: VMCore dir '/var/crash/127.0.0.1-2017-01-09-14:38:37' not accessible.

audit:
type=AVC msg=audit(1483969178.342:65): avc:  denied  { read } for  pid=2383 comm="abrt-harvest-vm" name="127.0.0.1-2017-01-09-14:38:37" dev="dm-5" ino=3201 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
type=SYSCALL msg=audit(1483969178.342:65): arch=c000003e syscall=257 success=no exit=-13 a0=ffffffffffffff9c a1=1627890 a2=90800 a3=0 items=0 ppid=1 pid=2383 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrt-harvest-vm" exe="/usr/bin/python2.7" subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null)

Comment 2 Lukas Vrabec 2017-01-10 23:34:05 UTC
Hi Frank,
Did you booted with SELinux disabled and then turned SELinux in enforcing mode again? 

Could you please run following command:
# restorecon -R / 

Then try to repeat the scenario? 

Thanks.

Comment 3 Frank Büttner 2017-01-12 08:13:26 UTC
Selinux was never disabled on this system.
before restorecon -R / :
ll -Z /var/ 
drwxr-xr-x. root      root          system_u:object_r:kdump_crash_t:s0 crash
after:
drwxr-xr-x. root      root          system_u:object_r:kdump_crash_t:s0 crash
trigger an kernel panic:
abrt-harvest-vmcore[2438]: VMCore dir '/var/crash/127.0.0.1-2017-01-12-09:03:13' not accessible.

But what I can see is:
ll -Z /var/crash/
drwxr-xr-x. root root system_u:object_r:kdump_crash_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_t:s0       ..
drwxr-xr-x. root root system_u:object_r:unlabeled_t:s0 127.0.0.1-2017-01-12-09:03:13

that the crash directory itself has an different context.  


restorecon -R /var/crash/
systemctl restart abrt-vmcore
systemctl reboot
Now the crash are recognized:
systemd[1]: Starting Harvest vmcores for ABRT...
systemd[1]: Started Harvest vmcores for ABRT.
abrt-dump-oops[2410]: Found oopses: 1
abrt-dump-oops[2410]: Updating problem directory

Comment 5 Milos Malik 2017-08-17 11:17:45 UTC
Hi Martin, could you help us to reproduce the issue? We need to know the SELinux labels of directories inside /var/crash directory.

# setenforce 0
# ls -Z /var/crash

It seems that /var/crash/127.0.0.1-2017-01-12-09:03:13 was created with an invalid SELinux label.

Comment 6 Lukas Vrabec 2017-10-12 12:17:45 UTC
We're going to close this bug as WONTFIX because

 * of limited capacity of selinux-policy developers
 * the bug is related to EPEL component or 3rd party SW only
 * the bug appears in unsupported configuration 

We believe this bug can be fixed via a local policy module.
For more information please see: 

 * https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-troubleshooting-fixing_problems#sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow

If you disagree, please re-open the bug.

Comment 7 Lukas Vrabec 2017-10-12 12:20:53 UTC
We're going to close this bug as WONTFIX because

 * of limited capacity of selinux-policy developers
 * the bug is related to EPEL component or 3rd party SW only
 * the bug appears in unsupported configuration 

We believe this bug can be fixed via a local policy module.
For more information please see: 

 * https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-troubleshooting-fixing_problems#sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow

If you disagree, please re-open the bug.


Note You need to log in before you can comment on or make changes to this bug.