node=gelk type=AVC msg=audit(1245532166.163:18): avc: denied { read } for pid=2931 comm="ifconfig" name="mls" dev=selinuxfs ino=12 scontext=unconfined_u:unconfined_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file node=gelk type=AVC msg=audit(1245532166.163:18): avc: denied { open } for pid=2931 comm="ifconfig" name="mls" dev=selinuxfs ino=12 scontext=unconfined_u:unconfined_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file node=gelk type=SYSCALL msg=audit(1245532166.163:18): arch=c000003e syscall=2 success=no exit=-1693835304 a0=7fffc079da70 a1=0 a2=7fffc079da7c a3=fffffff8 items=0 ppid=2915 pid=2931 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ifconfig" exe="/sbin/ifconfig" subj=unconfined_u:unconfined_r:ifconfig_t:s0-s0:c0.c1023 key=(null)
You can add these rules now using # grep avc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Fixed in selinux-policy-3.6.12-57.fc11
Similar problem: I was trying to connect to Internet with PPP over ATM by using "ifup ppp0" (which worked fine before last official update to selinux-policy-3.6.12-53.fc11). With SELinux policy targeted in enforcing mode, the connection doed not work and I got in /var/log/messages only this message: "pppd[3387]: Can't execute /etc/ppp/ip-down: Permission denied" Changing SELinux to permessive mode, the connection worked again, but SELinux complained: Summary: SELinux is preventing ifconfig (ifconfig_t) "read" security_t. Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by ifconfig. It is not expected that this access is required by ifconfig and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context unconfined_u:unconfined_r:ifconfig_t:SystemLow- SystemHigh Target Context system_u:object_r:security_t:SystemLow Target Objects mls [ file ] Source ifconfig Source Path /sbin/ifconfig Port <Unknown> Host ozzy Source RPM Packages net-tools-1.60-92.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-53.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name ozzy Platform Linux ozzy 2.6.29.5-191.fc11.i686.PAE #1 SMP Tue Jun 16 23:19:53 EDT 2009 i686 i686 Alert Count 2 First Seen Tue Jun 30 01:43:40 2009 Last Seen Tue Jun 30 01:43:40 2009 Local ID 8322622e-7836-4224-9459-818c551f475f Line Numbers Raw Audit Messages node=ozzy type=AVC msg=audit(1246319020.985:31): avc: denied { read } for pid=2513 comm="ifconfig" name="mls" dev=selinuxfs ino=12 scontext=unconfined_u:unconfined_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file node=ozzy type=AVC msg=audit(1246319020.985:31): avc: denied { open } for pid=2513 comm="ifconfig" name="mls" dev=selinuxfs ino=12 scontext=unconfined_u:unconfined_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=file node=ozzy type=SYSCALL msg=audit(1246319020.985:31): arch=40000003 syscall=5 success=yes exit=3 a0=bfa563c8 a1=8000 a2=0 a3=bfa563c8 items=0 ppid=2512 pid=2513 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ifconfig" exe="/sbin/ifconfig" subj=unconfined_u:unconfined_r:ifconfig_t:s0-s0:c0.c1023 key=(null) Then I found this bug report, so I downloaded and installed selinux-policy-3.6.12-62.fc11 from koji. Now in enforcing mode the connection continues to not workd and I still get "Can't execute /etc/ppp/ip-down: Permission denied", while in permessive mode the connection works but SELinux stopped complaining (only difference).
Could you run restorecon on this file restorecon -v /etc/ppp/ip-down
(In reply to comment #3) > Could you run restorecon on this file > > restorecon -v /etc/ppp/ip-down That did not print out anything. # ls -Z /etc/ppp/ip* -rwxr-xr-x. root root system_u:object_r:pppd_initrc_exec_t:SystemLow /etc/ppp/ip-down -rwxr-xr-x. root root system_u:object_r:bin_t:SystemLow /etc/ppp/ip-down.ipv6to4 -rwxr-xr-x. root root system_u:object_r:pppd_initrc_exec_t:SystemLow /etc/ppp/ip-up -rwxr-xr-x. root root system_u:object_r:bin_t:SystemLow /etc/ppp/ip-up.ipv6to4 -rwxr-xr-x. root root system_u:object_r:pppd_initrc_exec_t:SystemLow /etc/ppp/ipv6-down -rwxr-xr-x. root root system_u:object_r:pppd_initrc_exec_t:SystemLow /etc/ppp/ipv6-up BTW, trying to debug this I noticed that I have had enabled for years the SELinux boolean pppd_can_insmod, which I think should be the default, otherwise I have a lot of complaints like: SELinux is preventing the ppp daemon from inserting kernel modules. SELinux is preventing modprobe (pppd_t) "search" modules_object_t. SELinux is preventing modprobe (pppd_t) "getattr" modules_dep_t. SELinux is preventing modprobe (pppd_t) "read" modules_object_t.
Well the question then would be why doesn't the init script or start up script load the kernel module. We do not like to give confined applications the ability to load kernel modules, since they can modify the kernel and subvirt the securirty of the system.
Regarding the problem with "Can't execute /etc/ppp/ip-down: Permission denied", I opened a new bug report: https://bugzilla.redhat.com/show_bug.cgi?id=518118
ppp-2.4.4-12.fc11 is currently in testing state. *** This bug has been marked as a duplicate of bug 498789 ***
sorry, incorrect bug number
(In reply to comment #1) > You can add these rules now using > > # grep avc /var/log/audit/audit.log | audit2allow -M mypol > # semodule -i mypol.pp > > Fixed in selinux-policy-3.6.12-57.fc11 Thank you, after applying the above rules my SELinux has settled down.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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
I didn't understand if 'pppd_can_insmod on' fixes the issue or not. Was it intended se boolean should be 'on' by default? (this question is mainly to Nicola Soranzo) There is only one loading kernel module in ppp - when pppoatm plugin is loaded. There is no initscript and therefore loading module can't be pulled out of binary (or can but with direction ppp becomes 'user unfriendly' - future integration ppp over atm into NM). I see this boolean as a good option. Dan, what do you think?
(In reply to comment #11) > I didn't understand if 'pppd_can_insmod on' fixes the issue or not. Was it > intended se boolean should be 'on' by default? (this question is mainly to > Nicola Soranzo) With updated Fedora 11, I don't see anymore the above-mentioned: SELinux is preventing the ppp daemon from inserting kernel modules. SELinux is preventing modprobe (pppd_t) "search" modules_object_t. SELinux is preventing modprobe (pppd_t) "getattr" modules_dep_t. SELinux is preventing modprobe (pppd_t) "read" modules_object_t. with pppd_can_insmod 'off', so probably some change fixed the bug, even if I can't find anything related in the changelog.
I'm convinced the pppd_can_insmod should be reviewed. This option should control enabling/disabling loading kernel module by pppd. Pppd loads module only when usage of pppoatm plugin is configured.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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. Thank you for reporting this bug and we are sorry it could not be fixed.