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

*** Bug 1203146 has been marked as a duplicate of this bug. ***

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?

You are right. It was a typo. Sorry for that.

*** Bug 1200161 has been marked as a duplicate of this bug. ***

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.

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

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.

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

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

Created attachment 1063324 [details]
Patch proposal

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

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

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

(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

(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

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

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.

*** Bug 1278182 has been marked as a duplicate of this bug. ***

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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