[PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

[PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

[Julien Gomes]

Currently, all ipmr/ip6mr cache reports are sent through the
mroute/mroute6 socket only.
This forces the use of a single socket for mroute programming, cache
reports and, regarding ipmr, IGMP messages without Router Alert option
reception.

The present patches are aiming to send Netlink notifications in addition
to the existing igmpmsg/mrt6msg to give user programs a way to handle
cache reports in parallel with multiple sockets other than the
mroute/mroute6 socket.

Julien Gomes (3):
  rtnetlink: add NEWCACHEREPORT message type
  ipmr: add netlink notifications on igmpmsg cache reports
  ip6mr: add netlink notifications on mrt6msg cache reports

 include/uapi/linux/mroute.h    | 11 ++++++++
 include/uapi/linux/mroute6.h   | 11 ++++++++
 include/uapi/linux/rtnetlink.h |  3 ++
 net/ipv4/ipmr.c                | 63 ++++++++++++++++++++++++++++++++++++++++--
 net/ipv6/ip6mr.c               | 63 ++++++++++++++++++++++++++++++++++++++++--
 security/selinux/nlmsgtab.c    |  3 +-
 6 files changed, 149 insertions(+), 5 deletions(-)

-- 
2.13.1

[PATCH net-next 1/3] rtnetlink: add NEWCACHEREPORT message type

[Julien Gomes]

New NEWCACHEREPORT message type to be used for cache reports sent
via Netlink, effectively allowing splitting cache report reception from
mroute programming.

Suggested-by: Ryan Halbrook <halbrook@arista.com>
Signed-off-by: Julien Gomes <julien@arista.com>
---
 include/uapi/linux/rtnetlink.h | 3 +++
 security/selinux/nlmsgtab.c    | 3 ++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 564790e854f7..cd1afb900929 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -146,6 +146,9 @@ enum {
 	RTM_GETSTATS = 94,
 #define RTM_GETSTATS RTM_GETSTATS
 
+	RTM_NEWCACHEREPORT = 96,
+#define RTM_NEWCACHEREPORT RTM_NEWCACHEREPORT
+
 	__RTM_MAX,
 #define RTM_MAX		(((__RTM_MAX + 3) & ~3) - 1)
 };
diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c
index 5aeaf30b7a13..7b7433a1a34c 100644
--- a/security/selinux/nlmsgtab.c
+++ b/security/selinux/nlmsgtab.c
@@ -79,6 +79,7 @@ static const struct nlmsg_perm nlmsg_route_perms[] =
 	{ RTM_GETNSID,		NETLINK_ROUTE_SOCKET__NLMSG_READ  },
 	{ RTM_NEWSTATS,		NETLINK_ROUTE_SOCKET__NLMSG_READ },
 	{ RTM_GETSTATS,		NETLINK_ROUTE_SOCKET__NLMSG_READ  },
+	{ RTM_NEWCACHEREPORT,	NETLINK_ROUTE_SOCKET__NLMSG_READ },
 };
 
 static const struct nlmsg_perm nlmsg_tcpdiag_perms[] =
@@ -158,7 +159,7 @@ int selinux_nlmsg_lookup(u16 sclass, u16 nlmsg_type, u32 *perm)
 	switch (sclass) {
 	case SECCLASS_NETLINK_ROUTE_SOCKET:
 		/* RTM_MAX always point to RTM_SETxxxx, ie RTM_NEWxxx + 3 */
-		BUILD_BUG_ON(RTM_MAX != (RTM_NEWSTATS + 3));
+		BUILD_BUG_ON(RTM_MAX != (RTM_NEWCACHEREPORT + 3));
 		err = nlmsg_perm(nlmsg_type, perm, nlmsg_route_perms,
 				 sizeof(nlmsg_route_perms));
 		break;
-- 
2.13.1

[PATCH net-next 2/3] ipmr: add netlink notifications on igmpmsg cache reports

[Julien Gomes]

Add Netlink notifications on cache reports in ipmr, in addition to the
existing igmpmsg sent to mroute_sk.
Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV4_MROUTE.

MSGTYPE, VIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the
same data as their equivalent fields in the igmpmsg header.
PKT attribute is the packet sent to mroute_sk, without the added igmpmsg
header.

Suggested-by: Ryan Halbrook <halbrook@arista.com>
Signed-off-by: Julien Gomes <julien@arista.com>
---
 include/uapi/linux/mroute.h | 11 ++++++++
 net/ipv4/ipmr.c             | 63 +++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
index f904367c0cee..f6f9e01ee734 100644
--- a/include/uapi/linux/mroute.h
+++ b/include/uapi/linux/mroute.h
@@ -152,6 +152,17 @@ enum {
 };
 #define IPMRA_VIFA_MAX (__IPMRA_VIFA_MAX - 1)
 
+/* ipmr netlink cache report attributes */
+enum {
+	IPMRA_CACHEREPORTA_MSGTYPE,
+	IPMRA_CACHEREPORTA_VIF_ID,
+	IPMRA_CACHEREPORTA_SRC_ADDR,
+	IPMRA_CACHEREPORTA_DST_ADDR,
+	IPMRA_CACHEREPORTA_PKT,
+	__IPMRA_CACHEREPORTA_MAX
+};
+#define IPMRA_CACHEREPORTA_MAX (__IPMRA_CACHEREPORTA_MAX - 1)
+
 /* That's all usermode folks */
 
 #define MFC_ASSERT_THRESH (3*HZ)		/* Maximal freq. of asserts */
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 9374b99c7c17..6d1f4fae3749 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -109,6 +109,7 @@ static int __ipmr_fill_mroute(struct mr_table *mrt, struct sk_buff *skb,
 			      struct mfc_cache *c, struct rtmsg *rtm);
 static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
 				 int cmd);
+static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
 static void mroute_clean_tables(struct mr_table *mrt, bool all);
 static void ipmr_expire_process(unsigned long arg);
 
@@ -993,8 +994,7 @@ static void ipmr_cache_resolve(struct net *net, struct mr_table *mrt,
 	}
 }
 
-/* Bounce a cache query up to mrouted. We could use netlink for this but mrouted
- * expects the following bizarre scheme.
+/* Bounce a cache query up to mrouted and netlink.
  *
  * Called under mrt_lock.
  */
@@ -1060,6 +1060,8 @@ static int ipmr_cache_report(struct mr_table *mrt,
 		return -EINVAL;
 	}
 
+	igmpmsg_netlink_event(mrt, skb);
+
 	/* Deliver to mrouted */
 	ret = sock_queue_rcv_skb(mroute_sk, skb);
 	rcu_read_unlock();
@@ -2341,6 +2343,63 @@ static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
 		rtnl_set_sk_err(net, RTNLGRP_IPV4_MROUTE, err);
 }
 
+static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt)
+{
+	struct net *net = read_pnet(&mrt->net);
+	struct nlmsghdr *nlh;
+	struct rtgenmsg *rtgenm;
+	struct igmpmsg *msg;
+	struct sk_buff *skb;
+	int payloadlen;
+	int msgsize;
+
+	payloadlen = pkt->len - sizeof(struct igmpmsg);
+	msg = (struct igmpmsg *)skb_network_header(pkt);
+	msgsize = NLMSG_ALIGN(sizeof(struct rtgenmsg))
+			+ nla_total_size(1)
+					/* IPMRA_CACHEREPORTA_MSGTYPE */
+			+ nla_total_size(1)
+					/* IPMRA_CACHEREPORTA_VIF_ID */
+			+ nla_total_size(4)
+					/* IPMRA_CACHEREPORTA_SRC_ADDR */
+			+ nla_total_size(4)
+					/* IPMRA_CACHEREPORTA_DST_ADDR */
+			+ nla_total_size(payloadlen)
+					/* IPMRA_CACHEREPORTA_PKT */
+			;
+
+	skb = nlmsg_new(msgsize, GFP_ATOMIC);
+	if (!skb)
+		goto errout;
+
+	nlh = nlmsg_put(skb, 0, 0, RTM_NEWCACHEREPORT,
+			sizeof(struct rtgenmsg), 0);
+	if (!nlh)
+		goto errout;
+	rtgenm = nlmsg_data(nlh);
+	rtgenm->rtgen_family = RTNL_FAMILY_IPMR;
+	if (nla_put_u8(skb, IPMRA_CACHEREPORTA_MSGTYPE, msg->im_msgtype) ||
+	    nla_put_u8(skb, IPMRA_CACHEREPORTA_VIF_ID, msg->im_vif) ||
+	    nla_put_in_addr(skb, IPMRA_CACHEREPORTA_SRC_ADDR,
+			    msg->im_src.s_addr) ||
+	    nla_put_in_addr(skb, IPMRA_CACHEREPORTA_DST_ADDR,
+			    msg->im_dst.s_addr) ||
+	    nla_put(skb, IPMRA_CACHEREPORTA_PKT, payloadlen,
+		    pkt->data + sizeof(struct igmpmsg)))
+		goto nla_put_failure;
+
+	nlmsg_end(skb, nlh);
+
+	rtnl_notify(skb, net, 0, RTNLGRP_IPV4_MROUTE, NULL, GFP_ATOMIC);
+	return;
+
+nla_put_failure:
+	nlmsg_cancel(skb, nlh);
+errout:
+	kfree_skb(skb);
+	rtnl_set_sk_err(net, RTNLGRP_IPV4_MROUTE, -ENOBUFS);
+}
+
 static int ipmr_rtm_dumproute(struct sk_buff *skb, struct netlink_callback *cb)
 {
 	struct net *net = sock_net(skb->sk);
-- 
2.13.1

Re: [PATCH net-next 2/3] ipmr: add netlink notifications on igmpmsg cache reports

[Nicolas Dichtel]

Le 13/06/2017 à 19:08, Julien Gomes a écrit :
> Add Netlink notifications on cache reports in ipmr, in addition to the
> existing igmpmsg sent to mroute_sk.
> Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV4_MROUTE.
> 
> MSGTYPE, VIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the
> same data as their equivalent fields in the igmpmsg header.
> PKT attribute is the packet sent to mroute_sk, without the added igmpmsg
> header.
> 
> Suggested-by: Ryan Halbrook <halbrook@arista.com>
> Signed-off-by: Julien Gomes <julien@arista.com>
> ---
>  include/uapi/linux/mroute.h | 11 ++++++++
>  net/ipv4/ipmr.c             | 63 +++++++++++++++++++++++++++++++++++++++++++--
>  2 files changed, 72 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
> index f904367c0cee..f6f9e01ee734 100644
> --- a/include/uapi/linux/mroute.h
> +++ b/include/uapi/linux/mroute.h
> @@ -152,6 +152,17 @@ enum {
>  };
>  #define IPMRA_VIFA_MAX (__IPMRA_VIFA_MAX - 1)
>  
> +/* ipmr netlink cache report attributes */
> +enum {
IPMRA_CACHEREPORTA_UNSPEC is missing.
By the way, maybe something shorter than IPMRA_CACHEREPORTA_ would be better.
What about IPMR_CREPORTA_? IPMR_CACHEA_? IPMR_IGMPA_? or whatever.
What is the signification of the two 'A'? One for 'attribute', but the other?

> +	IPMRA_CACHEREPORTA_MSGTYPE,
> +	IPMRA_CACHEREPORTA_VIF_ID,
> +	IPMRA_CACHEREPORTA_SRC_ADDR,
> +	IPMRA_CACHEREPORTA_DST_ADDR,
> +	IPMRA_CACHEREPORTA_PKT,
> +	__IPMRA_CACHEREPORTA_MAX
> +};
> +#define IPMRA_CACHEREPORTA_MAX (__IPMRA_CACHEREPORTA_MAX - 1)

Re: [PATCH net-next 2/3] ipmr: add netlink notifications on igmpmsg cache reports

[Julien Gomes]

On 06/14/2017 12:56 AM, Nicolas Dichtel wrote:
> Le 13/06/2017 à 19:08, Julien Gomes a écrit :
>> Add Netlink notifications on cache reports in ipmr, in addition to the
>> existing igmpmsg sent to mroute_sk.
>> Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV4_MROUTE.
>>
>> MSGTYPE, VIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the
>> same data as their equivalent fields in the igmpmsg header.
>> PKT attribute is the packet sent to mroute_sk, without the added igmpmsg
>> header.
>>
>> Suggested-by: Ryan Halbrook <halbrook@arista.com>
>> Signed-off-by: Julien Gomes <julien@arista.com>
>> ---
>>  include/uapi/linux/mroute.h | 11 ++++++++
>>  net/ipv4/ipmr.c             | 63 +++++++++++++++++++++++++++++++++++++++++++--
>>  2 files changed, 72 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
>> index f904367c0cee..f6f9e01ee734 100644
>> --- a/include/uapi/linux/mroute.h
>> +++ b/include/uapi/linux/mroute.h
>> @@ -152,6 +152,17 @@ enum {
>>  };
>>  #define IPMRA_VIFA_MAX (__IPMRA_VIFA_MAX - 1)
>>  
>> +/* ipmr netlink cache report attributes */
>> +enum {
> IPMRA_CACHEREPORTA_UNSPEC is missing.

Indeed, I will add it.

> By the way, maybe something shorter than IPMRA_CACHEREPORTA_ would be better.
> What about IPMR_CREPORTA_? IPMR_CACHEA_? IPMR_IGMPA_? or whatever.

I see absolutely no issue in shortening them.
IPMRA_CREPORT_ sounds good to me.

> What is the signification of the two 'A'? One for 'attribute', but the other?

Now that you mention it, the second 'A' is simply redundant.
I will remove it and go with IPMRA_CREPORT_.

-- 
Julien Gomes

[PATCH net-next 3/3] ip6mr: add netlink notifications on mrt6msg cache reports

[Julien Gomes]

Add Netlink notifications on cache reports in ip6mr, in addition to the
existing mrt6msg sent to mroute6_sk.
Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV6_MROUTE.

MSGTYPE, MIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the
same data as their equivalent fields in the mrt6msg header.
PKT attribute is the packet sent to mroute6_sk, without the added
mrt6msg header.

Suggested-by: Ryan Halbrook <halbrook@arista.com>
Signed-off-by: Julien Gomes <julien@arista.com>
---
 include/uapi/linux/mroute6.h | 11 ++++++++
 net/ipv6/ip6mr.c             | 63 ++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
index ed5721148768..8e3c2d2c170e 100644
--- a/include/uapi/linux/mroute6.h
+++ b/include/uapi/linux/mroute6.h
@@ -133,4 +133,15 @@ struct mrt6msg {
 	struct in6_addr	im6_src, im6_dst;
 };
 
+/* ip6mr netlink cache report attributes */
+enum {
+	IP6MRA_CACHEREPORTA_MSGTYPE,
+	IP6MRA_CACHEREPORTA_MIF_ID,
+	IP6MRA_CACHEREPORTA_SRC_ADDR,
+	IP6MRA_CACHEREPORTA_DST_ADDR,
+	IP6MRA_CACHEREPORTA_PKT,
+	__IP6MRA_CACHEREPORTA_MAX
+};
+#define IP6MRA_CACHEREPORTA_MAX (__IP6MRA_CACHEREPORTA_MAX - 1)
+
 #endif /* _UAPI__LINUX_MROUTE6_H */
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 374997d26488..8667256b4343 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -116,6 +116,7 @@ static int __ip6mr_fill_mroute(struct mr6_table *mrt, struct sk_buff *skb,
 			       struct mfc6_cache *c, struct rtmsg *rtm);
 static void mr6_netlink_event(struct mr6_table *mrt, struct mfc6_cache *mfc,
 			      int cmd);
+static void mrt6msg_netlink_event(struct mr6_table *mrt, struct sk_buff *pkt);
 static int ip6mr_rtm_dumproute(struct sk_buff *skb,
 			       struct netlink_callback *cb);
 static void mroute_clean_tables(struct mr6_table *mrt, bool all);
@@ -1123,8 +1124,7 @@ static void ip6mr_cache_resolve(struct net *net, struct mr6_table *mrt,
 }
 
 /*
- *	Bounce a cache query up to pim6sd. We could use netlink for this but pim6sd
- *	expects the following bizarre scheme.
+ *	Bounce a cache query up to pim6sd and netlink.
  *
  *	Called under mrt_lock.
  */
@@ -1206,6 +1206,8 @@ static int ip6mr_cache_report(struct mr6_table *mrt, struct sk_buff *pkt,
 		return -EINVAL;
 	}
 
+	mrt6msg_netlink_event(mrt, skb);
+
 	/*
 	 *	Deliver to user space multicast routing algorithms
 	 */
@@ -2455,6 +2457,63 @@ static void mr6_netlink_event(struct mr6_table *mrt, struct mfc6_cache *mfc,
 		rtnl_set_sk_err(net, RTNLGRP_IPV6_MROUTE, err);
 }
 
+static void mrt6msg_netlink_event(struct mr6_table *mrt, struct sk_buff *pkt)
+{
+	struct net *net = read_pnet(&mrt->net);
+	struct nlmsghdr *nlh;
+	struct rtgenmsg *rtgenm;
+	struct mrt6msg *msg;
+	struct sk_buff *skb;
+	int payloadlen;
+	int msgsize;
+
+	payloadlen = pkt->len - sizeof(struct mrt6msg);
+	msg = (struct mrt6msg *)skb_transport_header(pkt);
+	msgsize = NLMSG_ALIGN(sizeof(struct rtgenmsg))
+			+ nla_total_size(1)
+					/* IP6MRA_CACHEREPORTA_MSGTYPE */
+			+ nla_total_size(2)
+					/* IP6MRA_CACHEREPORTA_MIF_ID */
+			+ nla_total_size(sizeof(struct in6_addr))
+					/* IP6MRA_CACHEREPORTA_SRC_ADDR */
+			+ nla_total_size(sizeof(struct in6_addr))
+					/* IP6MRA_CACHEREPORTA_DST_ADDR */
+			+ nla_total_size(payloadlen)
+					/* IP6MRA_CACHEREPORTA_PKT */
+			;
+
+	skb = nlmsg_new(msgsize, GFP_ATOMIC);
+	if (!skb)
+		goto errout;
+
+	nlh = nlmsg_put(skb, 0, 0, RTM_NEWCACHEREPORT,
+			sizeof(struct rtgenmsg), 0);
+	if (!nlh)
+		goto errout;
+	rtgenm = nlmsg_data(nlh);
+	rtgenm->rtgen_family = RTNL_FAMILY_IP6MR;
+	if (nla_put_u8(skb, IP6MRA_CACHEREPORTA_MSGTYPE, msg->im6_msgtype) ||
+	    nla_put_u16(skb, IP6MRA_CACHEREPORTA_MIF_ID, msg->im6_mif) ||
+	    nla_put_in6_addr(skb, IP6MRA_CACHEREPORTA_SRC_ADDR,
+			     &msg->im6_src) ||
+	    nla_put_in6_addr(skb, IP6MRA_CACHEREPORTA_DST_ADDR,
+			     &msg->im6_dst) ||
+	    nla_put(skb, IP6MRA_CACHEREPORTA_PKT, payloadlen,
+		    pkt->data + sizeof(struct mrt6msg)))
+		goto nla_put_failure;
+
+	nlmsg_end(skb, nlh);
+
+	rtnl_notify(skb, net, 0, RTNLGRP_IPV6_MROUTE, NULL, GFP_ATOMIC);
+	return;
+
+nla_put_failure:
+	nlmsg_cancel(skb, nlh);
+errout:
+	kfree_skb(skb);
+	rtnl_set_sk_err(net, RTNLGRP_IPV6_MROUTE, -ENOBUFS);
+}
+
 static int ip6mr_rtm_dumproute(struct sk_buff *skb, struct netlink_callback *cb)
 {
 	struct net *net = sock_net(skb->sk);
-- 
2.13.1

Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

[Nikolay Aleksandrov]

On 13/06/17 20:08, Julien Gomes wrote:
> Currently, all ipmr/ip6mr cache reports are sent through the
> mroute/mroute6 socket only.
> This forces the use of a single socket for mroute programming, cache
> reports and, regarding ipmr, IGMP messages without Router Alert option
> reception.
> 
> The present patches are aiming to send Netlink notifications in addition
> to the existing igmpmsg/mrt6msg to give user programs a way to handle
> cache reports in parallel with multiple sockets other than the
> mroute/mroute6 socket.
> 
> Julien Gomes (3):
>   rtnetlink: add NEWCACHEREPORT message type
>   ipmr: add netlink notifications on igmpmsg cache reports
>   ip6mr: add netlink notifications on mrt6msg cache reports
> 
>  include/uapi/linux/mroute.h    | 11 ++++++++
>  include/uapi/linux/mroute6.h   | 11 ++++++++
>  include/uapi/linux/rtnetlink.h |  3 ++
>  net/ipv4/ipmr.c                | 63 ++++++++++++++++++++++++++++++++++++++++--
>  net/ipv6/ip6mr.c               | 63 ++++++++++++++++++++++++++++++++++++++++--
>  security/selinux/nlmsgtab.c    |  3 +-
>  6 files changed, 149 insertions(+), 5 deletions(-)
> 

Hi Julien,
This has been on our todo list and I'm definitely interested in the implementation.
A few things that need careful consideration from my POV. First are the security
implications - this sends rtnl multicast messages but the rtnl socket has
the NL_CFG_F_NONROOT_RECV flag thus allowing any user on the system to listen in.
This would allow them to see the full packets and all reports (granted they can see
the notifications even now), but the full packet is like giving them the opportunity
to tcpdump the PIM traffic.
My second (more fixable and minor) concern is about the packet itself, how do you
know that the packet is all linear so you can directly copy it ?

Thanks,
 Nik

Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

[Julien Gomes]

Hi Nikolay,

On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:

> This has been on our todo list and I'm definitely interested in the implementation.
> A few things that need careful consideration from my POV. First are the security
> implications - this sends rtnl multicast messages but the rtnl socket has
> the NL_CFG_F_NONROOT_RECV flag thus allowing any user on the system to listen in.
> This would allow them to see the full packets and all reports (granted they can see
> the notifications even now), but the full packet is like giving them the opportunity
> to tcpdump the PIM traffic.

I definitely see how this can be an issue.
>From what I see, this means that either the packet should be
transmitted another way, or another Netlink family should be used.

NETLINK_ROUTE looks to be the logical family to choose though,
but then I do not see a proper other way to handle this.

However I may just not be looking into the right direction,
maybe you currently have another approach in mind?

> My second (more fixable and minor) concern is about the packet itself, how do you
> know that the packet is all linear so you can directly copy it ?

Indeed, I overlooked this possibility in this version.
I will improve that.

-- 
Julien Gomes

Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

[Nikolay Aleksandrov]

On 15/06/17 00:51, Julien Gomes wrote:
> Hi Nikolay,
> 
> On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
> 
>> This has been on our todo list and I'm definitely interested in the implementation.
>> A few things that need careful consideration from my POV. First are the security
>> implications - this sends rtnl multicast messages but the rtnl socket has
>> the NL_CFG_F_NONROOT_RECV flag thus allowing any user on the system to listen in.
>> This would allow them to see the full packets and all reports (granted they can see
>> the notifications even now), but the full packet is like giving them the opportunity
>> to tcpdump the PIM traffic.
> 
> I definitely see how this can be an issue.
> From what I see, this means that either the packet should be
> transmitted another way, or another Netlink family should be used.
> 
> NETLINK_ROUTE looks to be the logical family to choose though,
> but then I do not see a proper other way to handle this.

Right, currently me neither, unless it provides a bind callback when registering
the kernel socket.

> 
> However I may just not be looking into the right direction,
> maybe you currently have another approach in mind?

I haven't gotten around to make (or even try) them but I was thinking about 2 options
ending up with a similar result:

1) genetlink
 It also has the NONROOT_RECV flag, but it also allows for a callback - mcast_bind()
 which can be used to filter.

or

2) Providing a bind callback to the NETLINK_ROUTE socket.

I haven't checked in detail how feasible each option is. To me 2) seems like the
cleaner/proper way to do it but it requires extending the rtnetlink api.

It would be nice to get feedback and comments from more people on this.

> 
>> My second (more fixable and minor) concern is about the packet itself, how do you
>> know that the packet is all linear so you can directly copy it ?
> 
> Indeed, I overlooked this possibility in this version.
> I will improve that.
> 

Thanks!

Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

[Nikolay Aleksandrov]

On 15/06/17 14:33, Nikolay Aleksandrov wrote:
> On 15/06/17 00:51, Julien Gomes wrote:
>> Hi Nikolay,
>>
>> On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
>>
>>> This has been on our todo list and I'm definitely interested in the implementation.
>>> A few things that need careful consideration from my POV. First are the security
>>> implications - this sends rtnl multicast messages but the rtnl socket has
>>> the NL_CFG_F_NONROOT_RECV flag thus allowing any user on the system to listen in.
>>> This would allow them to see the full packets and all reports (granted they can see
>>> the notifications even now), but the full packet is like giving them the opportunity
>>> to tcpdump the PIM traffic.
>>
>> I definitely see how this can be an issue.
>> From what I see, this means that either the packet should be
>> transmitted another way, or another Netlink family should be used.
>>
>> NETLINK_ROUTE looks to be the logical family to choose though,
>> but then I do not see a proper other way to handle this.
> 
> Right, currently me neither, unless it provides a bind callback when registering
> the kernel socket.
> 
>>
>> However I may just not be looking into the right direction,
>> maybe you currently have another approach in mind?
> 
> I haven't gotten around to make (or even try) them but I was thinking about 2 options
> ending up with a similar result:
> 
> 1) genetlink
>  It also has the NONROOT_RECV flag, but it also allows for a callback - mcast_bind()
>  which can be used to filter.
> 
> or
> 
> 2) Providing a bind callback to the NETLINK_ROUTE socket.
> 

Ah nevermind, these cannot be used for filtering currently, so it seems
the netlink interface would need to be extended too if going down this road.

> I haven't checked in detail how feasible each option is. To me 2) seems like the
> cleaner/proper way to do it but it requires extending the rtnetlink api.
> 
> It would be nice to get feedback and comments from more people on this.
> 
>>
>>> My second (more fixable and minor) concern is about the packet itself, how do you
>>> know that the packet is all linear so you can directly copy it ?
>>
>> Indeed, I overlooked this possibility in this version.
>> I will improve that.
>>
> 
> Thanks!
> 

Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

[Nikolay Aleksandrov]

On 15/06/17 14:44, Nikolay Aleksandrov wrote:
> On 15/06/17 14:33, Nikolay Aleksandrov wrote:
>> On 15/06/17 00:51, Julien Gomes wrote:
>>> Hi Nikolay,
>>>
>>> On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
>>>
>>>> This has been on our todo list and I'm definitely interested in the implementation.
>>>> A few things that need careful consideration from my POV. First are the security
>>>> implications - this sends rtnl multicast messages but the rtnl socket has
>>>> the NL_CFG_F_NONROOT_RECV flag thus allowing any user on the system to listen in.
>>>> This would allow them to see the full packets and all reports (granted they can see
>>>> the notifications even now), but the full packet is like giving them the opportunity
>>>> to tcpdump the PIM traffic.
>>>
>>> I definitely see how this can be an issue.
>>> From what I see, this means that either the packet should be
>>> transmitted another way, or another Netlink family should be used.
>>>
>>> NETLINK_ROUTE looks to be the logical family to choose though,
>>> but then I do not see a proper other way to handle this.
>>
>> Right, currently me neither, unless it provides a bind callback when registering
>> the kernel socket.
>>
>>>
>>> However I may just not be looking into the right direction,
>>> maybe you currently have another approach in mind?
>>
>> I haven't gotten around to make (or even try) them but I was thinking about 2 options
>> ending up with a similar result:
>>
>> 1) genetlink
>>  It also has the NONROOT_RECV flag, but it also allows for a callback - mcast_bind()
>>  which can be used to filter.
>>
>> or
>>
>> 2) Providing a bind callback to the NETLINK_ROUTE socket.
>>
> 
> Ah nevermind, these cannot be used for filtering currently, so it seems
> the netlink interface would need to be extended too if going down this road.
> 

Sorry for the multiple emails, just to be thorough - again if going down this
road all of these would obviously require a different group to bind to in order
to be able to filter on it, because users must keep receiving their notifications
for the ipmr one.
Maybe alternative options should be considered, e.g. allowing multiple sockets
to receive the reports, but this is starting to sound like af_packet. :-)

>> I haven't checked in detail how feasible each option is. To me 2) seems like the
>> cleaner/proper way to do it but it requires extending the rtnetlink api.
>>
>> It would be nice to get feedback and comments from more people on this.
>>
>>>
>>>> My second (more fixable and minor) concern is about the packet itself, how do you
>>>> know that the packet is all linear so you can directly copy it ?
>>>
>>> Indeed, I overlooked this possibility in this version.
>>> I will improve that.
>>>
>>
>> Thanks!
>>
> 

Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

[Julien Gomes]

On 06/15/2017 06:00 AM, Nikolay Aleksandrov wrote:
> On 15/06/17 14:44, Nikolay Aleksandrov wrote:
>> On 15/06/17 14:33, Nikolay Aleksandrov wrote:
>>> On 15/06/17 00:51, Julien Gomes wrote:
>>>> Hi Nikolay,
>>>>
>>>> On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
>>>>
>>>>> This has been on our todo list and I'm definitely interested in the implementation.
>>>>> A few things that need careful consideration from my POV. First are the security
>>>>> implications - this sends rtnl multicast messages but the rtnl socket has
>>>>> the NL_CFG_F_NONROOT_RECV flag thus allowing any user on the system to listen in.
>>>>> This would allow them to see the full packets and all reports (granted they can see
>>>>> the notifications even now), but the full packet is like giving them the opportunity
>>>>> to tcpdump the PIM traffic.
>>>> I definitely see how this can be an issue.
>>>> From what I see, this means that either the packet should be
>>>> transmitted another way, or another Netlink family should be used.
>>>>
>>>> NETLINK_ROUTE looks to be the logical family to choose though,
>>>> but then I do not see a proper other way to handle this.
>>> Right, currently me neither, unless it provides a bind callback when registering
>>> the kernel socket.
>>>
>>>> However I may just not be looking into the right direction,
>>>> maybe you currently have another approach in mind?
>>> I haven't gotten around to make (or even try) them but I was thinking about 2 options
>>> ending up with a similar result:
>>>
>>> 1) genetlink
>>>  It also has the NONROOT_RECV flag, but it also allows for a callback - mcast_bind()
>>>  which can be used to filter.
>>>
>>> or
>>>
>>> 2) Providing a bind callback to the NETLINK_ROUTE socket.
>>>
>> Ah nevermind, these cannot be used for filtering currently, so it seems
>> the netlink interface would need to be extended too if going down this road.
>>
> Sorry for the multiple emails, just to be thorough - again if going down this
> road all of these would obviously require a different group to bind to in order
> to be able to filter on it, because users must keep receiving their notifications
> for the ipmr one.

Actually, using a bind callback for NETLINK_ROUTE with a new group,
without netlink interface extension, could  work.

I quickly tested something like this:
> static int rtnetlink_bind(struct net *net, int group)
> {
>     switch (group) {
>     case RTNLGRP_IPV4_MROUTE_R:
>     case RTNLGRP_IPV6_MROUTE_R:
>        if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
>            return -EPERM;
>        break;
>     }
>     return 0;
> }

With the addition of one/two groups this does restrict the reports'
potential listeners.
The group names here are just placeholders, I am not especially fixed
on these ones.

It is not perfect as this would introduce groups with specific
requirements in NETLINK_ROUTE, but I think it can be decent.

What do you think about this?

-- 
Julien Gomes

Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

[Nikolay Aleksandrov]

On 16/06/17 22:26, Julien Gomes wrote:
> On 06/15/2017 06:00 AM, Nikolay Aleksandrov wrote:
>> On 15/06/17 14:44, Nikolay Aleksandrov wrote:
>>> On 15/06/17 14:33, Nikolay Aleksandrov wrote:
>>>> On 15/06/17 00:51, Julien Gomes wrote:
>>>>> Hi Nikolay,
>>>>>
>>>>> On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
>>>>>
>>>>>> This has been on our todo list and I'm definitely interested in the implementation.
>>>>>> A few things that need careful consideration from my POV. First are the security
>>>>>> implications - this sends rtnl multicast messages but the rtnl socket has
>>>>>> the NL_CFG_F_NONROOT_RECV flag thus allowing any user on the system to listen in.
>>>>>> This would allow them to see the full packets and all reports (granted they can see
>>>>>> the notifications even now), but the full packet is like giving them the opportunity
>>>>>> to tcpdump the PIM traffic.
>>>>> I definitely see how this can be an issue.
>>>>> From what I see, this means that either the packet should be
>>>>> transmitted another way, or another Netlink family should be used.
>>>>>
>>>>> NETLINK_ROUTE looks to be the logical family to choose though,
>>>>> but then I do not see a proper other way to handle this.
>>>> Right, currently me neither, unless it provides a bind callback when registering
>>>> the kernel socket.
>>>>
>>>>> However I may just not be looking into the right direction,
>>>>> maybe you currently have another approach in mind?
>>>> I haven't gotten around to make (or even try) them but I was thinking about 2 options
>>>> ending up with a similar result:
>>>>
>>>> 1) genetlink
>>>>  It also has the NONROOT_RECV flag, but it also allows for a callback - mcast_bind()
>>>>  which can be used to filter.
>>>>
>>>> or
>>>>
>>>> 2) Providing a bind callback to the NETLINK_ROUTE socket.
>>>>
>>> Ah nevermind, these cannot be used for filtering currently, so it seems
>>> the netlink interface would need to be extended too if going down this road.
>>>
>> Sorry for the multiple emails, just to be thorough - again if going down this
>> road all of these would obviously require a different group to bind to in order
>> to be able to filter on it, because users must keep receiving their notifications
>> for the ipmr one.
> 
> Actually, using a bind callback for NETLINK_ROUTE with a new group,
> without netlink interface extension, could  work.
> 
> I quickly tested something like this:
>> static int rtnetlink_bind(struct net *net, int group)
>> {
>>     switch (group) {
>>     case RTNLGRP_IPV4_MROUTE_R:
>>     case RTNLGRP_IPV6_MROUTE_R:
>>        if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
>>            return -EPERM;
>>        break;
>>     }
>>     return 0;
>> }
> 
> With the addition of one/two groups this does restrict the reports'
> potential listeners.
> The group names here are just placeholders, I am not especially fixed
> on these ones.
> 
> It is not perfect as this would introduce groups with specific
> requirements in NETLINK_ROUTE, but I think it can be decent.
> 
> What do you think about this?
> 

Oh yes, that is exactly what I had in mind. I missed that the netns is passed
to the bind function.

Thanks,
 Nik