From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: When selinux (targeted) is enforcing, ADSL (pppoe) cannot be started at boot time. There appears to be no activity on the modem (external ethernet). Workaround: when selinux is permissive, ADSL (pppoe) stars fine at boot time, and no errors are logged. Is selinux stopping pppd from triggering the loading of the module for eth1? Version-Release number of selected component (if applicable): selinux-policy-targeted-1.25.1-9 How reproducible: Always Steps to Reproduce: 1. Enable enforcing for selinux (targeted) in the GNOME system security settings. 2. Reboot system Actual Results: Startup of ADSL (pppoe) failed at boot time. No modem activity lights, so no traffic on the eth1-modem link. Expected Results: ADSL (pppoe) should have started. Additional info: When the bug occurs, /var/log/messages contains 14 lines of the form below, varying only in the audit() id: Jul 16 11:31:11 ripley kernel: audit(1121484602.291:2): avc: denied { sys_module } for pid=1711 comm="pppoe" capability=16 scontext=system_u:system_r:pppd_t This system is a stock FC4 x86_64 Athlon64: Linux ripley 2.6.12-1.1390_FC4 #1 Tue Jul 5 19:55:49 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux eth1 is used to connect to the modem. Here is a dmesg snippet from when ADSL startup succeeds: 8139too Fast Ethernet driver 0.9.27 ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 16 (level, low) -> IRQ 201 eth1: RealTek RTL8139 at 0x9800, 00:10:b5:0d:75:c7, IRQ 201 eth1: Identified 8139 chip type 'RTL-8139C' eth1: link up, 10Mbps, half-duplex, lpa 0x0000 Is selinux preventing pppd from triggering the loading of this module?
It is also important to note that ADSL (pppoe) has *never* worked for me with selinux enforcing for any revision from FC4 base up to the current version (this is my first exposure to selinux). So Dan, this is not something that has been broken in your most recent updates to selinux-policy-targeted. Also, I thought I should mention that I need this line in my /etc/modprobe.conf to get the ethernet card going: alias eth1 8139too
Fixed in selinux-policy-targeted-1.25.2-4
This bug is not fixed in selinux-policy-targeted-1.25.2-4 I updated my system this morning (including selinux-policy-targeted-1.25.2-4), enabled selinux enforcing, and found that the original problem till persists (ADSL did not connect on system restart). My logs have fourteen lines like this (here is the first): Jul 19 06:36:06 ripley kernel: audit(1121726097.930:2): avc: denied { sys_module } for pid=1711 comm="pppoe" capability=16 scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=capability The workaround is still to disable selinux enforcing.
Comment made by Daniel Walsh to bugzilla_AT_redhat_dot_com: Setup the boolean pppd_can_insmod. setsebool -P pppd_can_insmod=1
ADSL still cannot connect after running "setsebool -P pppd_can_insmod=1" Procedure: (1) As root, ran "setsebool -P pppd_can_insmod=1" (2) Enabled selinux enforcing (3) Rebooted the system Same result as before: ADSL did not connect. Here is the first /var/log/messages entry of 14: Jul 20 06:23:19 ripley kernel: audit(1121811730.093:2): avc: denied { sys_module } for pid=1711 comm="pppoe" capability=16 scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=capability I have confirmed that pppd_can_insmod is set (after the reboot) with: # getsebool pppd_can_insmod pppd_can_insmod --> active
This bug is still present in selinux-policy-targeted-1.25.4-10. On 2 September I updated to selinux-policy-targeted-1.25.4-10. For good measure, I relabelled my entire filesystem. ADSL will still not start at boot time if selinux is set to enforcing. Here is the error (from /var/log/messages): Sep 2 07:11:18 ripley kernel: audit(1125616210.118:2): avc: denied { sys_module } for pid=1777 comm="pppoe" capability=16 scontext=system_u:system_r:pppd_t tcontext=system_u:system_r:pppd_t tclass=capability The system is a fully updated FC4 x86_64. Please let me know if you would like any further information.
Fixed in selinux-policy-*-1.27.1-2.1
ADSL still does not start at boot time with selinux-policy-targeted-1.27.1-2.1 set to enforcing. If enforcing is disabled, ADSL starts as expected. The only difference with this update is that no selinux errors are generated when ADSL fails to start at boot time: it just fails. When selinux is set to enforcing, there is no evidence of the 8139too module being loaded, and, of course, no activity in the (external) modem. As before, ADSL can be started by root by running "/etc/rc.d/init.d/network start" as root after boot time. ADSL starts normally at this time, even with selinux enforcing enabled. For good measure, after updating, I relabelled my entire filesystem (again), just to be sure, before running this test. Here is the updated system configuration: # rpm -q selinux-policy-targeted selinux-policy-targeted-1.27.1-2.1 # rpm -q kernel kernel-2.6.12-1.1456_FC4 # uname -a Linux ripley 2.6.12-1.1456_FC4 #1 Thu Sep 22 02:11:36 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux # date Sat Sep 24 10:32:44 WST 2005
Can you install policy sources. selinux-policy-targeted-sources Then execute cd /etc/selinux/targeted/src/policy make enableaudit; make load Then try the reboot sequence again. To revert back to not auditing everything you can execute cd /etc/selinux/targeted/src/policy make clean; make load
I have installed selinux-policy-targeted-sources-1.27.1-2.1, enabled auditing, and enabled enforcing. I have attached the portion of /var/log/messages ("messages.2005-09-25") corresponding to the following system restart. Of particular interest are the denied "nscd" hotplug_t entries just after ppp starts (search for "ppp"). Note that I am *not* running nscd. The reason I have included all of /var/log/messages for this restart is that there are some earlier hotplug denied entries that may be relevant.
Created attachment 119231 [details] Excerpt of /var/log/messages exhibiting the bug
Do you have a labeling problem with /usr? It looks like it is labeled file_t instead of usr_t?
I think the audit lines you are seeing are before /usr is mounted, when /usr is a mount point and just an ordinary file. Note that most kjournald entries (rc.sysinit running "mount -a"[?]) occur after all the name="usr" audit lines. No name="usr" audit lines occur once /usr is mounted. When /usr is mounted, it looks like it is labelled usr_t: # ls -d --lcontext /usr drwxr-xr-x 16 system_u:object_r:usr_t root root 4096 Jul 3 14:25 /usr And /var/run/ncsd is labelled nscd_var_run_t (see audit lines near ppp start): # ls -d --lcontext /var/run/nscd drwxr-xr-x 2 system_u:object_r:nscd_var_run_t root root 4096 Aug 15 22:16 /var/run/nscd All filesystems were created by the FC4 installation process, using the release FC4 ISO images, with selinux enabled. I have relabelled the filesystem twice since then, both times with all filesystems mounted, most recently after updating selinux-policy-targeted. Is there any significance to the name="nscd" hotplug_t nscd_var_run_t audit lines when ppp is starting?
I don't think nscd lines are a problems. I am thinking the problem has to do with the file_t lines. Was this log file generated when the machine was in permissive mode? Could you install selinux-policy-targeted-sources and add the lines allow hotplug_t file_t:dir search; allow hwclock_t file_t:dir search; allow kudzu_t file_t:dir search; to /etc/selinux/targeted/src/policy/domains/misc/local.te Then do a cd /etc/selinux/targeted/src/policy make load See if this solves the problem.
(1) The log file attached earlier was generated in enforcing mode. (2) I updated selinux to selinux-policy-targeted-1.27.1-2.2 and selinux-policy-targeted-sources-1.27.1-2.2, then added allow hotplug_t file_t:dir search; allow hwclock_t file_t:dir search; allow kudzu_t file_t:dir search; to /etc/selinux/targeted/src/policy/domains/misc/local.te then ran cd /etc/selinux/targeted/src/policy make load This did not solve the problem, that is, ADSL did not start on reboot.
But did you boot in permissive mode? If not, please do. Then grab the AVC messages when ADSL is successful. Dan
Created attachment 119395 [details] /var/log/messages for boot in permissive mode Here is /var/log/messages for a boot in permissive mode, with the three extra allow search options in local.te, and auditing enabled. ADSL starts correctly. There are some interesting avc entries immediately after ADSL start.
nscd denials are likely noise; glibc always tries to search for the nscd socket for name lookups, and if the search fails (due either to permission denial or absence of a running nscd), falls back to the normal lookup path. ifconfig denials are currently dontaudit'd, so that suggests that someone previously decided that they weren't actually needed. But it seems like they could be legitimate accesses for reading /proc/sys/net/ data. Might want to allow them. siginh/rlimitinh/noatsecure denials on the pppd_t -> initrc_t transition could be a problem, particularly noatsecure. That triggers glibc secure mode upon the domain transition, which forces sanitization of certain environment variables that might be getting used there. Might want to try allowing noatsecure there. ifconfig denial on pppd_t:fd use is likely not good; I'd allow it. Otherwise, ifconfig may end up with no stdout/stderr at all, not even the null device, which could break it. ntpd_t likely should have sys_nice; that seems legit.
Fixed in current release.
Still broken in selinux-policy-targeted-1.27.1-2.11. Same symptoms as before. With enableaudit, I get these when the adsl network device is started (ignoring all the nscd avc lines): Nov 5 09:30:53 ripley kernel: audit(1131154251.098:116): avc: denied { sys_module } for pid=1595 comm="ifconfig" capability=16 scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:ifconfig_t tclass=capability But the correct ethernet module for the network card is loaded. ADSL uses this device: Nov 5 09:30:54 ripley kernel: 8139too Fast Ethernet driver 0.9.27 Nov 5 09:30:54 ripley kernel: eth1: RealTek RTL8139 at 0x9800, 00:10:b5:0d:75:c7, IRQ 201 Does selinux restrict the ability of the networking scripts to configure this device for PPPoE?
This is what is logged with no auditing, with selinux in permissive mode: Nov 5 09:38:34 ripley kernel: 8139too Fast Ethernet driver 0.9.27 Nov 5 09:38:34 ripley kernel: ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 16 (level, low) -> IRQ 201 Nov 5 09:38:34 ripley kernel: eth1: RealTek RTL8139 at 0x9800, 00:10:b5:0d:75:c7, IRQ 201 Nov 5 09:38:34 ripley kernel: eth1: link up, 10Mbps, half-duplex, lpa 0x0000 Nov 5 09:38:34 ripley kernel: CSLIP: code copyright 1989 Regents of the University of California Nov 5 09:38:34 ripley kernel: PPP generic driver version 2.4.2 Nov 5 09:38:34 ripley kernel: NET: Registered protocol family 10 Nov 5 09:38:34 ripley kernel: Disabled Privacy Extensions on device ffffffff8051ff00(lo) Nov 5 09:38:34 ripley kernel: IPv6 over IPv4 tunneling driver Nov 5 09:38:36 ripley pppd[1638]: PAP authentication succeeded With selinux enforcing, I never see any line containing "eth1: link up, 10Mbps, half-duplex, lpa 0x0000" or like the lines following it.
Added boolean to selinux-policy-targeted-1.27.1-2.15 Which allows sys_module Upgrade to this policy then execute setsebool -P allow_ifconfig_sys_module=1
I upgraded to selinux-policy-targeted-1.27.1-2.16 and ran setsebool -P allow_ifconfig_sys_module=1 I enabled selinux enforcing and restarted the system. ADSL started correctly at boot time, with selinux enforcing, so this policy change has fixed the bug. Thanks very much.
Closing as these have been marked as modified, for a while. Feel free to reopen if not fixed