Bug 241401

Any thing in /var/log/audit/audit.log?  

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.

Doesn't work for me in F7 install, unless I put selinux into permissive mode.
There are no denials, just 'ioctl: no such device'.

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

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)

Ok, if you add this rule does it work

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

Does this work with the current policy?  In Rawhide?

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.

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.

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

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.

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);
 }
 
 /**

Wouldn't doing so break *all* people who do aliases in modprobe.conf for modules?

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.

Yeah, but I'm not sure it's worth breaking that just to allow a policy change.

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.

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?

Stepping back - are these modules being loaded *directly* by /sbin/ip, or
indirectly by request_module() when poked by /sbin/ip?

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

Ok, it will be allowed in selinux-policy-3.0.8-38.fc8

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.

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