Bug 495189 - SELinux is preventing radvd (radvd_t) "sys_module" radvd_t
SELinux is preventing radvd (radvd_t) "sys_module" radvd_t
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: radvd (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Skala
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-10 03:28 EDT by Allen Kistler
Modified: 2014-11-09 17:31 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-30 09:21:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Allen Kistler 2009-04-10 03:28:51 EDT
Description of problem:
When radvd starts, but the interface from which it derives its IPv6 prefix does not yet exist (like if ppp is down), then radvd attempts a sys_module action, but gets denied.

Version-Release number of selected component (if applicable):
selinux-policy-3.3.1-130.fc9

How reproducible:
Always

Steps to Reproduce:
1. Configure radvd to get its public address from ppp
2. Verify ppp is down
3. Start radvd
  
Actual results:
AVC denial

Expected results:
No denial

Additional info:

No doubt the same is true in F10 and F11, too.

Raw Audit Messages            

node=ack604 type=AVC msg=audit(1239347194.320:765): avc:  denied  { sys_module } for  pid=8668 comm="radvd" capability=16 scontext=unconfined_u:system_r:radvd_t:s0 tcontext=unconfined_u:system_r:radvd_t:s0 tclass=capability
Comment 1 Daniel Walsh 2009-04-13 08:20:50 EDT
Isn't there a better way to do this?  Any chance this functionality could be moved to the init script or a separate executable.  We try to limit the amount of processes that can modify the kernel.
Comment 2 Bug Zapper 2009-06-09 23:39:53 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 WONTFIX if it remains open with a Fedora 
'version' of '9'.

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 prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Allen Kistler 2009-06-10 00:31:31 EDT
I'll be retesting with F11.
It should happen before F9's EOL.
Comment 4 Allen Kistler 2009-06-28 17:28:22 EDT
The bug is still there in F11.

When starting radvd without ppp0 existing, radvd prints (twice):

[Jun 28 16:07:06] radvd: ioctl(SIOCGIFADDR) failed for ppp0: No such device
[Jun 28 16:07:06] radvd: interface ppp0 has no IPv4 addresses, disabling 6to4 prefix


And the following shows up in the audit log (also twice):

type=AVC msg=audit(1246223226.836:2573): avc:  denied  { sys_module } for  pid=19423 comm="radvd" capability=16 scontext=unconfined_u:system_r:radvd_t:s0 tcontext=unconfined_u:system_r:radvd_t:s0 tclass=capability

type=SYSCALL msg=audit(1246223226.836:2573): arch=40000003 syscall=54 success=no exit=-19 a0=6 a1=8915 a2=bf8a76fc a3=6 items=0 ppid=19422 pid=19423 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=252 comm="radvd" exe="/usr/sbin/radvd" subj=unconfined_u:system_r:radvd_t:s0 key=(null)


FWIW, the SELinux denial doesn't seem to hurt anything.  When ppp0 comes up, my setup automatically runs /etc/ppp/ip-up.ipv6to4, which picks up "IPV6_CONTROL_RADVD=yes" and makes radvd distribute the new 6to4 prefix fine.

In other words, I'm not in any hurry to allow the sys_module action, whatever it may be trying to do.
Comment 5 Jiri Skala 2009-09-21 10:33:28 EDT
Radvd tests an interface defined in the radvd.conf. When the test fails and the modules are not loaded the AVC denial is generated. Radvd doesn't try to load any kernel module.

Radvd is stopped when the interface is not activated independently on AVC denial.

Radvd provides IgnoreIfMissing option that makes possible to continue when interface is not activated. The AVC denial doesn't affect this.
Comment 6 Miroslav Grepl 2009-09-21 11:21:21 EDT
Dan,

then I guess we can dontaudit this.
Comment 7 Daniel Walsh 2009-09-21 22:37:26 EDT
Yes and I think in F12 it will get the kernel module loaded via a request_module.
Comment 8 Eric Paris 2009-09-22 00:11:34 EDT
Yes, in F12 it will be a request_module instead of a sys_module.
Comment 9 Jiri Skala 2009-09-30 09:21:18 EDT
It should be fixed in selinux-policy in rawhide - correct me if I'm wrong. So I'll close it.

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