[SMACK-discuss] [PATCH RFC] Smack: More sanity in the use of Netlabel

[Piotr Sawicki]

I'm sorry for the late reply. We had a public holiday yesterday.

On 06/14/2017 06:39 PM, Casey Schaufler wrote:
>>>    #if IS_ENABLED(CONFIG_IPV6)
>>>        case PF_INET6:
>>> -        proto = smk_skb_to_addr_ipv6(skb, &sadd);
>>> -        if (proto != IPPROTO_UDP && proto != IPPROTO_TCP)
>>> +        rc = smk_skb_to_addr_ipv6(skb, &sadd);
>>> +        if (rc != IPPROTO_UDP && rc != IPPROTO_TCP)
>>>                break;
>>
>> The PF_INET6 socket may receive IPv4 packets too. In this case smk_skb_to_addr_ipv6() returns -EINVAL or some rubbish value. Furthermore, the smk_skb_to_addr_ipv6() function returns a detected protocol type (e.g. DCCP). If it is neither TCP nor UDP, then the packet will be blocked.
> 
> Which behavior do you think would be proper? I can't tell if
> this is an observation or a complaint.

This is an observation. I've checked it on the Tizen emulator. A SSH 
server running on it uses a listening socket bound to the [::] IPv6 
address (IN6ADDR_ANY_INIT). This socket has also the IPV6_V6ONLY option 
turned off. All this means that, it can accept not only IPv6 but also 
IPv4 connections. When I was trying to make a SSH connection to the 
emulator using its IPv4 address, I noticed that incoming IPv4 packets 
were handled by the section of code intended for handling IPv6 traffic 
(sk->sk_family == PF_INET6). Because the smk_skb_to_addr_ipv6() had not 
been designed for processing IPv4 packets, this function returned some 
garbage values. In result all the SSH traffic was blocked.

I think that this issue would be readily fixed by checking the protocol 
field of an incoming skb, in the same way as the 
selinux_socket_sock_rcv_skb() function does (security/selinux/hooks.c). 
Moreover, smack_socket_sock_rcv_skb() should return 0 (accept) when the 
type of transport layer protocol of an incoming skb is neither TCP nor 
UDP. The other transport protocols, which are not taken into account, 
shouldn't be blocked.

>>
>> I wonder why are the other protocols not handled here (e.g. UDP Lite, DCCP)?
> 
> No one has asked for it. Patches welcome!
> 

OK. I will try to prepare a patch that handles the other kinds of protocols.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html