Bug 1181308 - SELinux is preventing /usr/sbin/rngd from 'execmod' accesses on the file /usr/sbin/rngd.
Summary: SELinux is preventing /usr/sbin/rngd from 'execmod' accesses on the file /usr...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: rng-tools
Version: 23
Hardware: i686
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:68e865d3815bc8a42a2f642ebc6...
: 1200161 1203146 1278182 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-12 20:28 UTC by ignazio.majo
Modified: 2017-02-14 11:43 UTC (History)
38 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-20 13:09:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch proposal (1.15 KB, patch)
2015-08-15 21:04 UTC, dave.null
no flags Details | Diff

Description ignazio.majo 2015-01-12 20:28:09 UTC
Description of problem:
SELinux is preventing /usr/sbin/rngd from 'execmod' accesses on the file /usr/sbin/rngd.

*****  Plugin catchall (100. confidence) suggests   **************************

If si crede che rngd dovrebbe avere possibilità di accesso execmod sui rngd file in modo predefinito.
Then si dovrebbe riportare il problema come bug.
E' possibile generare un modulo di politica locale per consentire questo accesso.
Do
consentire questo accesso per il momento eseguendo:
# grep rngd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:rngd_t:s0
Target Context                unconfined_u:object_r:rngd_exec_t:s0
Target Objects                /usr/sbin/rngd [ file ]
Source                        rngd
Source Path                   /usr/sbin/rngd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           rng-tools-5-4.fc21.i686
Target RPM Packages           rng-tools-5-4.fc21.i686
Policy RPM                    selinux-policy-3.13.1-103.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.17.8-300.fc21.i686 #1 SMP Fri
                              Jan 9 00:05:48 UTC 2015 i686 i686
Alert Count                   2
First Seen                    2015-01-12 19:32:52 CET
Last Seen                     2015-01-12 20:08:08 CET
Local ID                      f170cdaf-f70b-446a-a201-549fa38811f9

Raw Audit Messages
type=AVC msg=audit(1421089688.216:18): avc:  denied  { execmod } for  pid=655 comm="rngd" path="/usr/sbin/rngd" dev="dm-1" ino=2371968 scontext=system_u:system_r:rngd_t:s0 tcontext=unconfined_u:object_r:rngd_exec_t:s0 tclass=file permissive=0


type=SYSCALL msg=audit(1421089688.216:18): arch=i386 syscall=mprotect success=no exit=EACCES a0=b775c000 a1=5000 a2=5 a3=bfd57e20 items=0 ppid=1 pid=655 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=rngd exe=/usr/sbin/rngd subj=system_u:system_r:rngd_t:s0 key=(null)

Hash: rngd,rngd_t,rngd_exec_t,file,execmod

Version-Release number of selected component:
selinux-policy-3.13.1-103.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.8-300.fc21.i686
type:           libreport

Comment 1 Lukas Vrabec 2015-03-23 00:38:46 UTC

*** This bug has been marked as a duplicate of bug 1172235 ***

Comment 2 Miroslav Grepl 2015-04-03 15:51:28 UTC
*** Bug 1203146 has been marked as a duplicate of this bug. ***

Comment 3 DO NOT USE account not monitored (old adamwill) 2015-04-28 18:38:26 UTC
To the layman, https://bugzilla.redhat.com/show_bug.cgi?id=1172235 is completely different from this - was closing this as a dupe of that a typo?

Comment 4 Lukas Vrabec 2015-04-29 09:55:19 UTC
You are right. It was a typo. Sorry for that.

Comment 5 Adam Williamson 2015-05-12 00:48:18 UTC
*** Bug 1200161 has been marked as a duplicate of this bug. ***

Comment 6 Adam Williamson 2015-05-12 00:54:44 UTC
So this also came up as part of an F22 blocker bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1200161

that included two AVCs, one of which was fixed, the other looks the same as this. That bug was re-assigned to rng-tools for input from the maintainer, but never got any; CCing him here. Also CCing zbyszek because when you change a neglected package, you get the prize of being bugged about it for the next five years!

I'm re-proposing it as a blocker: the other bug was accepted, but AFAIK no-one else has reported seeing this AVC in testing, so it doesn't look like it *always* happens, but it's contingent on...something? Hardware? So probably needs re-discussing.

Comment 7 Zbigniew Jędrzejewski-Szmek 2015-05-12 13:13:02 UTC
This report and the two duplicates are all for i686. They would match a missing PIE compilation option, according to [1], but I don't see anything wrong in the build log. Compilation and linking looks like this:

gcc -DHAVE_CONFIG_H -I.     -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -c rngd.c

gcc  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables  -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o rngd rngd.o rngd_entsource.o rngd_linux.o util.o rngd_rdrand.o rdrand_asm.o librngd.a 


[1] http://www.akkadia.org/drepper/selinux-mem.html

Comment 8 Adam Williamson 2015-05-14 18:42:05 UTC
I tested an i686 install to a KVM and didn't reproduce this. Perhaps it needs i686 and real hardware RNG, or something? In any case, based on my testing I'm -1 blocker, it doesn't seem to happen often enough to count as a violation of the criterion.

Comment 9 Kamil Páral 2015-05-14 18:51:02 UTC
Discussed at the 2015-05-14 blocker review meeting.[1] Voted as RejectedBlocker - this does not appear to be commonly enough encountered to count as a violation of the criterion, we have tried quite a lot and cannot reproduce it

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-14

Comment 10 Bishal Thapa 2015-06-08 22:05:43 UTC
Description of problem:
I don't know

Version-Release number of selected component:
selinux-policy-3.13.1-126.fc22.noarch

Additional info:
reporter:       libreport-2.5.1
hashmarkername: setroubleshoot
kernel:         4.0.4-303.fc22.i686
type:           libreport

Comment 11 dave.null 2015-08-15 21:04:16 UTC
Created attachment 1063324 [details]
Patch proposal

Comment 12 dave.null 2015-08-15 21:07:57 UTC
I've hit the same issue on one of my system. When looking in the code I may have
found the culprit code:

in rngd_rdrand.c:

113 /* Calling cpuid instruction to verify rdrand and aes-ni capability */
114 static void cpuid(unsigned int leaf, unsigned int subleaf, struct cpuid *out)
115 {
116 #ifdef __i386__
117     /* %ebx is a forbidden register if we compile with -fPIC or -fPIE */
118     asm volatile("movl %%ebx,%0 ; cpuid ; xchgl %%ebx,%0"
119                  : "=r" (out->ebx),
120                    "=a" (out->eax),
121                    "=c" (out->ecx),
122                    "=d" (out->edx)
123                  : "a" (leaf), "c" (subleaf));
124 #else
125     asm volatile("cpuid"
126                  : "=b" (out->ebx),
127                    "=a" (out->eax),
128                    "=c" (out->ecx),
129                    "=d" (out->edx)
130                  : "a" (leaf), "c" (subleaf));
131 #endif
132 }

The file rdrand_asm.S also uses a lot the %ebx register.

My best fix right now is to disable the RdRand support on i386.
See my attached patch proposal "rng-tools-5-fix-i686-pie.patch".

The make sure I'm correct, doing "readelf -d rndg | grep TEXTREL" on an original build will show:
0x00000016 (TEXTREL)                    0x0

With my patch, readelf no longer show TEXTREL. When this patched binary is put on my system showing the issue, selinux will let systemd start rngd as before (the hardened build).

Comment 13 Ralf Corsepius 2015-09-18 03:43:27 UTC
Any progress on this BZ? I have been facing it for quite some time on fc22/i686:

# sealert -l bb9f32f0-5993-4e0d-ac18-dd4200ea9b02
SELinux is preventing rngd from execmod access on the file /usr/sbin/rngd.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that rngd should be allowed execmod access on the rngd file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep rngd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:rngd_t:s0
Target Context                system_u:object_r:rngd_exec_t:s0
Target Objects                /usr/sbin/rngd [ file ]
Source                        rngd
Source Path                   rngd
Port                          <Unknown>
Host                          mccallum
Source RPM Packages           
Target RPM Packages           rng-tools-5-4.fc22.i686
Policy RPM                    selinux-policy-3.13.1-128.13.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     mccallum
Platform                      Linux mccallum 4.1.6-201.fc22.i686+PAE #1 SMP Fri
                              Sep 4 18:07:07 UTC 2015 i686 i686
Alert Count                   43
First Seen                    2015-05-03 09:36:19 CEST
Last Seen                     2015-09-17 18:01:25 CEST
Local ID                      bb9f32f0-5993-4e0d-ac18-dd4200ea9b02

Raw Audit Messages
type=AVC msg=audit(1442505685.700:92): avc:  denied  { execmod } for  pid=627 comm="rngd" path="/usr/sbin/rngd" dev="dm-1" ino=1179783 scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:object_r:rngd_exec_t:s0 tclass=file permissive=0


Hash: rngd,rngd_t,rngd_exec_t,file,execmod

Comment 14 dave.null 2015-09-18 08:50:17 UTC
On my side, my patched rngd disabling RdRand with the attached patch worked
fine for one full month.

This ticket should probably be reassigned to the "rngd" component instead of
"selinux-policy", since it's rngd that needs a change anyway.

bug 1217941 seems to be a duplicate of this one. As Ralf pointed out, this
issue also occurs on f22 i686 (f23 probably affected too).

Comment 15 Ralf Corsepius 2015-09-18 10:21:01 UTC
(In reply to dave.null from comment #14)
> On my side, my patched rngd disabling RdRand with the attached patch worked
> fine for one full month.
Well, I am not sure about this patch, because IIUC, it disables RdRand entirely on all i386-variants, something I don't know, whether it would be correct.

So far, I have been observing this issue on a ca. 2000/2001 Pentium III and an on a ca. 2008/2009 Atom N270/i686-netbook.

> This ticket should probably be reassigned to the "rngd" component instead of
> "selinux-policy", since it's rngd that needs a change anyway.
I am inclined to agree.

> bug 1217941 seems to be a duplicate of this one. As Ralf pointed out, this
> issue also occurs on f22 i686 (fc23 probably affected too).
And yes, the bug is present on fc23 as well (Here w/ Atom N270/fc23).

# sealert -l a98647c8-a95e-4c1a-9d44-a537a6004d3c
SELinux is preventing rngd from execmod access on the file /usr/sbin/rngd.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that rngd should be allowed execmod access on the rngd file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep rngd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:rngd_t:s0
Target Context                system_u:object_r:rngd_exec_t:s0
Target Objects                /usr/sbin/rngd [ file ]
Source                        rngd
Source Path                   rngd
Port                          <Unknown>
Host                          gunvald1
Source RPM Packages           
Target RPM Packages           rng-tools-5-5.fc23.i686
Policy RPM                    selinux-policy-3.13.1-144.fc23.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     gunvald1
Platform                      Linux gunvald1 4.2.0-300.fc23.i686+PAE #1 SMP Fri
                              Sep 4 13:46:40 UTC 2015 i686 i686
Alert Count                   1
First Seen                    2015-09-18 12:14:47 CEST
Last Seen                     2015-09-18 12:14:47 CEST
Local ID                      a98647c8-a95e-4c1a-9d44-a537a6004d3c

Raw Audit Messages
type=AVC msg=audit(1442571287.891:82): avc:  denied  { execmod } for  pid=861 comm="rngd" path="/usr/sbin/rngd" dev="dm-0" ino=261288 scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:object_r:rngd_exec_t:s0 tclass=file permissive=0


Hash: rngd,rngd_t,rngd_exec_t,file,execmod

Comment 16 dave.null 2015-09-18 13:09:11 UTC
(In reply to Ralf Corsepius from comment #15)
> (In reply to dave.null from comment #14)
> > On my side, my patched rngd disabling RdRand with the attached patch worked
> > fine for one full month.
> Well, I am not sure about this patch, because IIUC, it disables RdRand
> entirely on all i386-variants, something I don't know, whether it would be
> correct.
> 
> So far, I have been observing this issue on a ca. 2000/2001 Pentium III and
> an on a ca. 2008/2009 Atom N270/i686-netbook.

I agree that the real fix would be to keep RdRand, not using %ebx on i686,
compiling rngd with -fPIE and keeping SELinux forbidding relocations. I don't
know if it's possible to satisfy all those constraints.

The patch I proposed was more a proof of concept, and a temporary one for me,
because I way prefer having a rngd working without RdRand (and with -fPIE),
than having no rngd at all (or modifying the SELinux policy). And it's been
a while this issue is opened, december 2014, according to the commit:

http://pkgs.fedoraproject.org/cgit/rng-tools.git/commit/?h=f21&id=95fb228e859df8162028819da0b6d31e9e1a708a

Comment 17 Marcio 2015-09-27 12:37:23 UTC
Description of problem:

Opening Google Chrome

Version-Release number of selected component:
selinux-policy-3.13.1-128.13.fc22.noarch

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.1.7-200.fc22.i686
type:           libreport

Comment 18 Fedora End Of Life 2015-11-04 15:18:14 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 '21'.

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 21 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.

Comment 19 Miroslav Grepl 2015-11-09 19:20:00 UTC
*** Bug 1278182 has been marked as a duplicate of this bug. ***

Comment 20 Jeffrey Walton 2015-11-14 09:09:33 UTC
> > > fine for one full month.
> > Well, I am not sure about this patch, because IIUC, it disables RdRand
> > entirely on all i386-variants, something I don't know, whether it would be
> > correct.
> > 
> > So far, I have been observing this issue on a ca. 2000/2001 Pentium III and
> > an on a ca. 2008/2009 Atom N270/i686-netbook.
> 
> I agree that the real fix would be to keep RdRand, not using %ebx on i686,
> compiling rngd with -fPIE and keeping SELinux forbidding relocations. I don't
> know if it's possible to satisfy all those constraints.

For give my ignorance... EBX is the GOT pointer in this particular case. The GOT (and hence EBX) is used depending on (1) the memory model, and (2) the use of PIC. Preserving EBX is all cases seems to be the simplest solution.

I used similar code in the past, but I could not get the assembled code to pass an audit. I thought it might have something to do with a lack of early clobber on EBX. In the end, I gave up because we should not waste hours on trying to audit code generation.

Under GCC __cpuid is available. It seems like a questionable strategy to re-invent the wheel instead of using what GCC provides.

There's also __builtin_cpu_supports("rdrnd"), __builtin_cpu_supports("rdseed") and friends. Again, it avoids re-inventing the wheel.

Once you determine CPU support, there are intrinsics available from <x86intrin.h> to avoid the inline assembly. They provide _rdrand64_step (and friends), and _rdseed64_step (and friends).

*****

With that said, what does this have to do with a SELinux violation? I'm testing the Crypto++ library (http://www.cryptopp.com/), and its triggering the violation too.

Are there ways to disable SELinux for this event?

(This is where my ignorance shows).

Comment 21 Jarmel 2015-11-19 11:53:55 UTC
Description of problem:
The problem occured after the first update the new installation OS via Yum Extender.

Version-Release number of selected component:
selinux-policy-3.13.1-122.fc22.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.0.4-301.fc22.i686
type:           libreport

Comment 22 Jarmel 2015-11-20 09:07:59 UTC
Description of problem:
This problem occured during installation any audio and video software via yum extender.

Version-Release number of selected component:
selinux-policy-3.13.1-128.18.fc22.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.2.6-200.fc22.i686
type:           libreport

Comment 23 Mark 2016-01-24 22:28:50 UTC
Description of problem:
I have no idea.. sorry.

Version-Release number of selected component:
selinux-policy-3.13.1-158.2.fc23.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.3.3-301.fc23.i686
type:           libreport

Comment 24 Amanjot Singh 2016-01-25 01:20:37 UTC
Description of problem:
when i turned on the laptop . i found "?" sign in notification bar instead of wifi sign. Then i turned off and on wifi . after that this problem came .

Version-Release number of selected component:
selinux-policy-3.13.1-158.fc23.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.2.8-300.fc23.i686
type:           libreport

Comment 25 Jeffrey Walton 2016-01-25 01:27:21 UTC
(In reply to Amanjot Singh from comment #24)
> Description of problem:
> when i turned on the laptop . i found "?" sign in notification bar instead
> of wifi sign. Then i turned off and on wifi . after that this problem came .

I have not encountered this in a while, so I can't test the machine I encountered it on...

You might try relabeling. Relabeling the File System is discussed at "45.2.2. Relabeling a File System", http://www.centos.org/docs/5/html/5.2/Deployment_Guide/sec-sel-fsrelabel.html. I'm not sure how to relabel arbitrary objects.

Comment 26 Gunter Halil 2016-02-15 11:35:14 UTC
Description of problem:
the problem becomes when did update the system.

Version-Release number of selected component:
selinux-policy-3.13.1-152.fc23.noarch

Additional info:
reporter:       libreport-2.6.4
hashmarkername: setroubleshoot
kernel:         4.2.3-300.fc23.i686
type:           libreport

Comment 27 Alan Kusov 2016-02-21 10:49:24 UTC
Description of problem:
New update may be. 

Version-Release number of selected component:
selinux-policy-3.13.1-158.4.fc23.noarch

Additional info:
reporter:       libreport-2.6.4
hashmarkername: setroubleshoot
kernel:         4.3.5-300.fc23.i686
type:           libreport

Comment 28 Hugo Leonardo R. D. Lopes 2016-03-04 17:32:17 UTC
Description of problem:
Java and icedtea

Version-Release number of selected component:
selinux-policy-3.13.1-158.7.fc23.noarch

Additional info:
reporter:       libreport-2.6.4
hashmarkername: setroubleshoot
kernel:         4.4.3-300.fc23.i686
type:           libreport

Comment 29 Aditya bohra 2016-03-31 19:21:57 UTC
Description of problem:
I don't know how this bug came.
I just turned on  my laptop then a notification showed up showing this bug. that's it I don't even know what is bug about.

Version-Release number of selected component:
selinux-policy-3.13.1-128.21.fc22.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.2.6-201.fc22.i686
type:           libreport

Comment 30 robert fairbrother 2016-06-18 20:12:20 UTC
Description of problem:
thesystem recently froze up but the hard disk is still verry active im using ssd

Version-Release number of selected component:
selinux-policy-3.13.1-158.15.fc23.noarch

Additional info:
reporter:       libreport-2.6.4
hashmarkername: setroubleshoot
kernel:         4.5.6-200.fc23.i686
type:           libreport

Comment 31 Fedora End Of Life 2016-11-24 11:22:16 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. 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 '23'.

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 23 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.

Comment 32 Fedora End Of Life 2016-12-20 13:09:38 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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.

Comment 33 Alexander 2017-02-14 11:43:15 UTC
Description of problem:
I'm just user, please send new update to resolve issues OS Fedora project!
Best regards!

Version-Release number of selected component:
selinux-policy-3.13.1-158.24.fc23.noarch

Additional info:
reporter:       libreport-2.6.4
hashmarkername: setroubleshoot
kernel:         4.8.13-100.fc23.i686
type:           libreport


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