[SMACK-discuss] [PATCH RFC] Smack: More sanity in the use of Netlabel
p.sawicki2 at partner.sasmung.com
Fri Jun 16 11:05:09 UTC 2017
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)
>> 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
More information about the Linux-security-module-archive