Bug 241401 - IPv6 tunnel setup fails
IPv6 tunnel setup fails
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-25 14:27 EDT by David Woodhouse
Modified: 2014-03-16 23:06 EDT (History)
4 users (show)

See Also:
Fixed In Version: selinux-policy-3.0.8-38.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 21:49:36 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 David Woodhouse 2007-05-25 14:27:29 EDT
Install clean FC6+updates.
Set up /etc/sysconfig/network-scripts/ifcfg-tun0 something like the following:

TYPE=sit
DEVICETYPE=sit
ONBOOT=yes
DEVICE=tun0
BOOTPROTO=none
IPV6INIT=yes
IPV6ADDR=2001:xxxx:xxxx:ff00::1/128
USERCTL=no
PEERDNS=no
IPV6TUNNELIPV4=yy.yy.yy.yy
IPV6TUNNELIPV4LOCAL=xx.xx.xx.xx
MTU=1400

This fails to work at bootup, but runs OK if I 'ifup tun0' later. Turning off
SElinux seems to fix it. I don't recall seeing any denials.
Comment 1 Daniel Walsh 2007-05-29 10:18:41 EDT
Any thing in /var/log/audit/audit.log?  
Comment 2 David Woodhouse 2007-05-29 10:31:17 EDT
For reasons unclear to me, this machine doesn't _have_ /var/log/audit/audit.log.
Could it have been removed when I removed the audit package? I don't _recall_
seeing anything there when I looked, but I was in a hurry at the time and just
disabled SElinux to get it to work (sorry).

Logs in /var/log/messages don't go far enough back to show anything interesting.

It should be relatively easy to reproduce with FC6 packages of about February
vintage. OTOH, if it doesn't happen with a clean F7 install or with a _current_
FC6 install, we might as well just close this bug WORKSFORME.
Comment 3 David Woodhouse 2007-05-29 13:24:22 EDT
Doesn't work for me in F7 install, unless I put selinux into permissive mode.
There are no denials, just 'ioctl: no such device'.
Comment 4 Daniel Walsh 2007-05-29 13:46:55 EDT
Execute the following.

sermodule -b /usr/share/selinux/targeted/enableaudit.pp

Sounds like tunnel is attempting to talk to a terminal device and it is being
dontaudited.  Probably needs to be allowed.  What device is it trying to ioctl?

The following will reenable to dontaudit rules.


sermodule -b /usr/share/selinux/targeted/base.pp
Comment 5 David Woodhouse 2007-05-29 14:31:37 EDT
avc: denied { sys_module } for pid=1650 comm="ip" capability=16
scontext=system_u:system_r:ifconfig_t:s0
tcontext=system_u:system_r:ifconfig_t:s0 tclass=capability

socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x89f1, 0xffb927dc)            = -1 ENODEV (No such device)
Comment 6 Daniel Walsh 2007-05-30 13:30:40 EDT
Ok, if you add this rule does it work

# grep sys_module /var/log/audit/audit.log | audit2allow -M myifconfig
# semodule -i myifconfig.pp

Comment 7 Daniel Walsh 2007-09-10 10:48:30 EDT
Does this work with the current policy?  In Rawhide?
Comment 8 David Woodhouse 2007-10-23 07:49:57 EDT
Still doesn't work in rawhide. It seems that 'enableaudit.pp' no longer exists,
and piping the above-quoted denial into 'audit2allow -M myifconfig' seems to
result in a module which doesn't load:

[root@ps3 ~]# echo 'avc: denied { sys_module } for pid=1650 comm="ip"
capability=16 scontext=system_u:system_r:ifconfig_t:s0
tcontext=system_u:system_r:ifconfig_t:s0 tclass=capability' | audit2allow -M
myifconfig
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i myifconfig.pp

[root@ps3 ~]# semodule -i myifconfig.pp 
libsepol.check_assertion_helper: assertion on line 0 violated by allow
ifconfig_t ifconfig_t:capability { sys_module };
libsepol.check_assertions: 1 assertion violations occured
libsemanage.semanage_expand_sandbox: Expand module failed
semodule:  Failed!



You ought to be able to test this locally.
Comment 9 Daniel Walsh 2007-10-23 09:06:35 EDT
semodule -DB replaces enableaudit.


The problem here is that ip command is trying to modify the load a kernel module.

This is currently dontaudited in poliyc

grep module ../system/sysnetwork.te 
policy_module(sysnetwork,1.4.1)
dontaudit dhcpc_t self:capability { dac_read_search sys_module };
dontaudit ifconfig_t self:capability sys_module;

Since the ability to modify the kernel is a pretty dangerous thing, we tend to
frown on people doing it, thus the assertion vialoation above.  The fear is
these tools listen to packets on the wire and if they can be fooled to load a
random kernel module, the systems can become subverted.

If you used the interface
kernel_load_module(ifconfig_t) 
Your policy would work and load.  But that is not a a great solution.  I can add
a boolean to policy to allow ifconfig to load the module, but is there any way
this could be done differently.
Comment 10 David Woodhouse 2007-10-24 03:48:37 EDT
We do allow the initscripts to invoke modprobe directly, even though we don't
let them load modules implicitly through ioctls. This patch should fix the
problem -- do we have any other cases where the initscripts rely on implicitly
loading modules?

(Going off at a tangent... we should probably avoid the 'load random module'
attack by prefixing the requested name with "netdevice:" when we call modprobe,
so that only modules which actually _intend_ to provide a network device with
that name would be selected).

--- ifup-sit~   2007-10-24 08:49:28.000000000 +0100
+++ ifup-sit    2007-10-24 08:41:58.000000000 +0100
@@ -73,6 +73,7 @@ if [ $? = 0 ]; then
 fi
 
 # Create tunnel
+/sbin/modprobe sit
 ipv6_add_tunnel_device $DEVICE $IPV6TUNNELIPV4 "" $IPV6TUNNELIPV4LOCAL || exit 1
 
 # Set IPv6 MTU, if given
Comment 11 Bill Nottingham 2007-10-24 14:24:41 EDT
Well, there are lots of cases where 'ip ... dev XXX' will try to load module
XXX. Whether that's a bug or a feature is up in the air. For 'ifup', it's
probably a feature. for 'ifdown', it's a bug.
Comment 12 David Woodhouse 2007-10-26 15:03:41 EDT
Straw man... (adding davem to cc)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -972,7 +972,7 @@ void dev_load(struct net *net, const char *name)
        read_unlock(&dev_base_lock);
 
        if (!dev && capable(CAP_SYS_MODULE))
-               request_module("%s", name);
+               request_module("netdevice:%s", name);
 }
 
 /**
Comment 13 Bill Nottingham 2007-10-26 15:06:45 EDT
Wouldn't doing so break *all* people who do aliases in modprobe.conf for modules?
Comment 14 David Woodhouse 2007-10-26 15:52:40 EDT
Yeah, but that mostly broke already since almost everything is detectable by
hotplug these days and the modules get loaded automatically, in some arbitrary
order, anyway.

So it'd break for people who have stuff like 'alias eth0 3c509' (for the
non-ISAPNP cards, at least), but I suspect that's not so common.
Comment 15 Bill Nottingham 2007-10-26 16:06:58 EDT
Yeah, but I'm not sure it's worth breaking that just to allow a policy change.
Comment 16 David Miller 2007-10-26 19:50:51 EDT
I don't think this fix is appropriate.

You should find some way to allow 'ip' to load modules
as this is how tunnels are setup properly.  Hacking
around it in scripts is also not a good idea, because we
don't want users propagating this hack into their
scripts too.

Finally, it should go without saying that I should be
able to say "ip foo" on the command line and it works.

I also agree with Bill that the suggested kernel change
cannot even be considered because it potentially breaks
too much stuff.
Comment 17 David Woodhouse 2007-10-26 22:09:17 EDT
Do you have a suggestion? 

It seems sane enough that the selinux policy should refuse to allow arbitrary
modules to be loaded -- if we don't want to fix the namespace issue, I don't see
that changing. If we don't want to have to load the module explicitly in the 
selinux-enforcing case, what's left?
Comment 18 Bill Nottingham 2007-10-26 23:48:44 EDT
Stepping back - are these modules being loaded *directly* by /sbin/ip, or
indirectly by request_module() when poked by /sbin/ip?
Comment 19 David Miller 2007-10-27 01:49:23 EDT
Indirectly by request_module(), that's why David's patch was editing
the kernel.

Users can pass arbitray strings in here which I why I guess it's
not allowed.

I really wish SELINUX wouldn't get in the way of basic functionlity
like this.  Programs like /sbin/ip are privileged applications that
change arbitrary networking state, they may need to load modules
in order to do that, what's the big deal?

And they can't load "arbitrary" modules.  They can only load the
modules which are installed and visible to modprobe.

Even so much as openning an IPV6 socket attempts to load the protocol
module, for example.  /sbin/ip's case is no different
Comment 20 Daniel Walsh 2007-10-27 06:31:48 EDT
Ok, it will be allowed in selinux-policy-3.0.8-38.fc8
Comment 21 Bug Zapper 2008-04-03 20:55:50 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 22 Bug Zapper 2008-05-06 21:49:34 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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