tun/tap and SE Linux in 2.6.32

tun/tap and SE Linux in 2.6.32

[Russell Coker]

----------  Forwarded Message  ----------

Subject: selinux permissive blocking tun/tap device creation in v2.6.32
Date: Wed, 9 Dec 2009
From: Andrew Worsley <amworsley@gmail.com>
To: luv-main@luv.asn.au

I upgraded to the v2.6.32 kernel and I found tunctl would fail with
the  ioctl TUNSETIFF rejected with an EINVAL. A real pain when running
vpn and kvms which use these.

I don't know where to go from this - so directions as to where to post
/ look would be appreciated but at least I can now create tap
interfaces.

I am looking for suggestions where I should post this to find a fix or
other better work around than merely commenting out this code...

   Andrew

I eventually traced this via recompiling the tun module with tracing
to this code:


            printk(KERN_INFO "tun: tun_set_iff () 10\n");
                if (!capable(CAP_NET_ADMIN))
                        return -EPERM;
            printk(KERN_INFO "tun: tun_set_iff () 11\n");
#if 0
                err = security_tun_dev_create();
                if (err < 0)
                        return err;
#endif

            printk(KERN_INFO "tun: tun_set_iff () 12\n");
                /* Set dev type */
                if (ifr->ifr_flags & IFF_TUN) {
                        /* TUN device */

in drivers/net/tun.c (commenting out the above allows the tunctl
command to work!)

Tracing this back a bit I think it's this code:

int avc_has_perm(u32 ssid, u32 tsid, u16 tclass,
                 u32 requested, struct common_audit_data *auditdata)
{
        struct av_decision avd;
        int rc;

        rc = avc_has_perm_noaudit(ssid, tsid, tclass, requested, 0, &avd);
        avc_audit(ssid, tsid, tclass, requested, &avd, rc, auditdata);
        return rc;
}

in security/selinux/avc.c which doesn't check for permissive mode or
sellinux disabled as other code in the same file appears to.

I believe this is called from:

static int selinux_tun_dev_create(void)
{
        u32 sid = current_sid();

        /* we aren't taking into account the "sockcreate" SID since the socket
         * that is being created here is not a socket in the traditional 
sense,
         * instead it is a private sock, accessible only to the kernel, and
         * representing a wide range of network traffic spanning multiple
         * connections unlike traditional sockets - check the TUN driver to
         * get a better understanding of why this socket is special */

        return avc_has_perm(sid, sid, SECCLASS_TUN_SOCKET, TUN_SOCKET__CREATE,
                            NULL);
}
 in security/selinux/hooks.c

-------------------------------------------------------

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: tun/tap and SE Linux in 2.6.32

[Paul Moore]

On Tuesday 08 December 2009 08:32:24 pm Russell Coker wrote:
> ----------  Forwarded Message  ----------
> 
> Subject: selinux permissive blocking tun/tap device creation in v2.6.32
> Date: Wed, 9 Dec 2009
> From: Andrew Worsley <amworsley@gmail.com>
> To: luv-main@luv.asn.au
> 
> I upgraded to the v2.6.32 kernel and I found tunctl would fail with
> the  ioctl TUNSETIFF rejected with an EINVAL. A real pain when running
> vpn and kvms which use these.
> 
> I don't know where to go from this - so directions as to where to post
> / look would be appreciated but at least I can now create tap
> interfaces.
> 
> I am looking for suggestions where I should post this to find a fix or
> other better work around than merely commenting out this code...
> 
>    Andrew
> 
> I eventually traced this via recompiling the tun module with tracing
> to this code:
> 
> 
>             printk(KERN_INFO "tun: tun_set_iff () 10\n");
>                 if (!capable(CAP_NET_ADMIN))
>                         return -EPERM;
>             printk(KERN_INFO "tun: tun_set_iff () 11\n");
> #if 0
>                 err = security_tun_dev_create();
>                 if (err < 0)
>                         return err;
> #endif
> 
>             printk(KERN_INFO "tun: tun_set_iff () 12\n");
>                 /* Set dev type */
>                 if (ifr->ifr_flags & IFF_TUN) {
>                         /* TUN device */
> 
> in drivers/net/tun.c (commenting out the above allows the tunctl
> command to work!)

I imagine this is because the original reporter is using a SELinux policy 
without the new TUN socket classes/permissions (which is likely the common 
case at this point).  The unknown class/permission handling that Eric added 
_should_ protect us from this - Russel do you have any more information about 
the distribution and policy in use here?  

-- 
paul moore
linux @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: tun/tap and SE Linux in 2.6.32

[Russell Coker]

On Thu, 10 Dec 2009, Paul Moore <paul.moore@hp.com> wrote:
> > Subject: selinux PERMISSIVE blocking tun/tap device creation in v2.6.32
>
> I imagine this is because the original reporter is using a SELinux policy
> without the new TUN socket classes/permissions (which is likely the common
> case at this point).  The unknown class/permission handling that Eric added
> _should_ protect us from this - Russel do you have any more information
> about the distribution and policy in use here?

Sorry, the original message apparently wasn't clear enough (I've added some 
caps).

The problem occurred in permissive mode.  When the system is in permissive 
mode then SE Linux should not deny any action that Unix permissions will 
permit.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: tun/tap and SE Linux in 2.6.32

[Stephen Smalley]

On Thu, 2009-12-10 at 07:56 +1100, Russell Coker wrote:
> On Thu, 10 Dec 2009, Paul Moore <paul.moore@hp.com> wrote:
> > > Subject: selinux PERMISSIVE blocking tun/tap device creation in v2.6.32
> >
> > I imagine this is because the original reporter is using a SELinux policy
> > without the new TUN socket classes/permissions (which is likely the common
> > case at this point).  The unknown class/permission handling that Eric added
> > _should_ protect us from this - Russel do you have any more information
> > about the distribution and policy in use here?
> 
> Sorry, the original message apparently wasn't clear enough (I've added some 
> caps).
> 
> The problem occurred in permissive mode.  When the system is in permissive 
> mode then SE Linux should not deny any action that Unix permissions will 
> permit.

That would require changing avc_has_perm_noaudit() or
context_struct_compute_av(), which historically have not treated an
error condition (e.g. invalid SID or class) within *compute_av() in the
same manner as lack of permission in the policy.  In the error condition
case, avc_has_perm_noaudit() just propagates the error condition to the
caller and permissive mode doesn't come into play - it doesn't even look
at (or cache) the av_decision.

That said, we've long since made the invalid SID case unreachable
(automatic remapping to the unlabeled SID), and we've now made the
invalid class case only an error if handle_unknown==deny, so possibly we
could change *compute_av() or avc_has_perm() to treat it the same way as
a regular permission denial.  We could possibly make *compute_av()
always "succeed" and just return the empty allowed vector (already
cleared on entry) on all error conditions, in which case avc_has_perm()
would always do the right thing.  And *compute_av() would become void
functions then.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: tun/tap and SE Linux in 2.6.32

[Paul Moore]

On Wednesday 09 December 2009 03:56:22 pm Russell Coker wrote:
> On Thu, 10 Dec 2009, Paul Moore <paul.moore@hp.com> wrote:
> > > Subject: selinux PERMISSIVE blocking tun/tap device creation in v2.6.32
> >
> > I imagine this is because the original reporter is using a SELinux policy
> > without the new TUN socket classes/permissions (which is likely the
> > common case at this point).  The unknown class/permission handling that
> > Eric added _should_ protect us from this - Russel do you have any more
> > information about the distribution and policy in use here?
> 
> Sorry, the original message apparently wasn't clear enough (I've added some
> caps).
> 
> The problem occurred in permissive mode.  When the system is in permissive
> mode then SE Linux should not deny any action that Unix permissions will
> permit.

Yes, I agree.  The avc_has_perm_noaudit() function, which is called by 
avc_has_perm(), checks to see if the system is in enforcing or permissive mode 
and does the right thing ... except for one case that I can see, the case 
where security_compute_av() returns an error/non-zero value.

Looking at security_compute_av() there is definitely code that will return an 
error, even the EINVAL that was reported, but it would appear to only be 
possible if the allow unknown classes/permissions flag was set to "no".  Could 
you please verify with the original reporter that this is the case?  It would 
also be interesting to see which distribution is shipping policy that has this 
flag set to "no".

        requested = unmap_perm(orig_tclass, orig_requested);
        tclass = unmap_class(orig_tclass);
        if (unlikely(orig_tclass && !tclass)) {
                if (policydb.allow_unknown)
                        goto allow;
                rc = -EINVAL;
                goto out;
        }

As for fixing this, there are a few options that I can think of, one of which 
is to change avc_has_perm_noaudit() so that it does not return a error code, 
only access denials.


-- 
paul moore
linux @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.