Bug 163425 - ADSL (pppoe) will not start when selinux (targeted) is enforcing
ADSL (pppoe) will not start when selinux (targeted) is enforcing
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-16 00:13 EDT by Ben Caradoc-Davies
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: policy-1.27.1-2.10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-05 11:01:27 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)
Excerpt of /var/log/messages exhibiting the bug (98.45 KB, text/plain)
2005-09-24 22:15 EDT, Ben Caradoc-Davies
no flags Details
/var/log/messages for boot in permissive mode (29.25 KB, text/plain)
2005-09-28 19:58 EDT, Ben Caradoc-Davies
no flags Details

  None (edit)
Description Ben Caradoc-Davies 2005-07-16 00:13:48 EDT
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?
Comment 1 Ben Caradoc-Davies 2005-07-16 00:23:44 EDT
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

Comment 2 Daniel Walsh 2005-07-16 07:06:01 EDT
Fixed in selinux-policy-targeted-1.25.2-4
Comment 3 Ben Caradoc-Davies 2005-07-18 19:17:14 EDT
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 4 David Lawrence 2005-07-19 11:22:58 EDT
Comment made by Daniel Walsh to bugzilla_AT_redhat_dot_com:

Setup the boolean pppd_can_insmod.

setsebool -P pppd_can_insmod=1
Comment 5 Ben Caradoc-Davies 2005-07-19 18:39:57 EDT
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

Comment 6 Ben Caradoc-Davies 2005-09-15 20:41:13 EDT
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.
Comment 7 Daniel Walsh 2005-09-19 16:20:17 EDT
Fixed in selinux-policy-*-1.27.1-2.1
Comment 8 Ben Caradoc-Davies 2005-09-23 23:35:52 EDT
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
Comment 9 Daniel Walsh 2005-09-24 06:53:16 EDT
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
Comment 10 Ben Caradoc-Davies 2005-09-24 22:13:26 EDT
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.
Comment 11 Ben Caradoc-Davies 2005-09-24 22:15:22 EDT
Created attachment 119231 [details]
Excerpt of /var/log/messages exhibiting the bug
Comment 12 Daniel Walsh 2005-09-26 11:26:56 EDT
Do you have a labeling problem with /usr?  It looks like it is labeled file_t
instead of usr_t?

Comment 13 Ben Caradoc-Davies 2005-09-26 19:03:37 EDT
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?
Comment 14 Daniel Walsh 2005-09-27 08:35:41 EDT
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.

Comment 15 Ben Caradoc-Davies 2005-09-27 20:36:03 EDT
(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.
Comment 16 Daniel Walsh 2005-09-28 10:53:53 EDT
But did you boot in permissive mode?

If not, please do.

Then grab the AVC messages when ADSL is successful.

Dan
Comment 17 Ben Caradoc-Davies 2005-09-28 19:58:11 EDT
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.
Comment 18 Stephen Smalley 2005-09-29 09:50:24 EDT
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.





Comment 19 Daniel Walsh 2005-11-03 18:02:07 EST
Fixed in current release.
Comment 20 Ben Caradoc-Davies 2005-11-04 20:56:23 EST
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?
Comment 21 Ben Caradoc-Davies 2005-11-04 21:14:39 EST
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.


Comment 22 Daniel Walsh 2005-11-30 17:01:24 EST
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

Comment 23 Ben Caradoc-Davies 2005-12-09 19:02:10 EST
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.

Comment 26 Daniel Walsh 2006-05-05 11:01:27 EDT
Closing as these have been marked as modified, for a while.  Feel free to reopen
if not fixed

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