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
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 <redacted>
Signed-off-by: Julien Gomes <redacted>
---
include/uapi/linux/mroute6.h | 11 ++++++++
net/ipv6/ip6mr.c | 63 ++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 72 insertions(+), 2 deletions(-)
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 <redacted>
Signed-off-by: Julien Gomes <redacted>
---
include/uapi/linux/mroute.h | 11 ++++++++
net/ipv4/ipmr.c | 63 +++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 72 insertions(+), 2 deletions(-)
@@ -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-*expectsthefollowingbizarrescheme.+/* Bounce a cache query up to mrouted and netlink.**Calledundermrt_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();
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 <redacted>
Signed-off-by: Julien Gomes <redacted>
---
include/uapi/linux/rtnetlink.h | 3 +++
security/selinux/nlmsgtab.c | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
From: Nicolas Dichtel <hidden> Date: 2017-06-14 07:56:23
Le 13/06/2017 à 19:08, Julien Gomes a écrit :
quoted hunk
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 <redacted>
Signed-off-by: Julien Gomes <redacted>
---
include/uapi/linux/mroute.h | 11 ++++++++
net/ipv4/ipmr.c | 63 +++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 72 insertions(+), 2 deletions(-)
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?
From: Nikolay Aleksandrov <hidden> Date: 2017-06-14 12:04:13
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
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 <redacted>
Signed-off-by: Julien Gomes <redacted>
---
include/uapi/linux/mroute.h | 11 ++++++++
net/ipv4/ipmr.c | 63 +++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 72 insertions(+), 2 deletions(-)
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
From: Nikolay Aleksandrov <hidden> Date: 2017-06-15 11:33:52
On 15/06/17 00:51, Julien Gomes wrote:
Hi Nikolay,
On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
quoted
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.
quoted
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.
From: Nikolay Aleksandrov <hidden> Date: 2017-06-15 11:44:43
On 15/06/17 14:33, Nikolay Aleksandrov wrote:
On 15/06/17 00:51, Julien Gomes wrote:
quoted
Hi Nikolay,
On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
quoted
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.
quoted
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.
quoted
quoted
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.
From: Nikolay Aleksandrov <hidden> Date: 2017-06-15 13:00:30
On 15/06/17 14:44, Nikolay Aleksandrov wrote:
On 15/06/17 14:33, Nikolay Aleksandrov wrote:
quoted
On 15/06/17 00:51, Julien Gomes wrote:
quoted
Hi Nikolay,
On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
quoted
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.
quoted
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. :-)
quoted
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.
quoted
quoted
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.
On 06/15/2017 06:00 AM, Nikolay Aleksandrov wrote:
On 15/06/17 14:44, Nikolay Aleksandrov wrote:
quoted
On 15/06/17 14:33, Nikolay Aleksandrov wrote:
quoted
On 15/06/17 00:51, Julien Gomes wrote:
quoted
Hi Nikolay,
On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
quoted
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.
quoted
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
From: Nikolay Aleksandrov <hidden> Date: 2017-06-17 13:35:47
On 16/06/17 22:26, Julien Gomes wrote:
On 06/15/2017 06:00 AM, Nikolay Aleksandrov wrote:
quoted
On 15/06/17 14:44, Nikolay Aleksandrov wrote:
quoted
On 15/06/17 14:33, Nikolay Aleksandrov wrote:
quoted
On 15/06/17 00:51, Julien Gomes wrote:
quoted
Hi Nikolay,
On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote:
quoted
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.
quoted
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:
quoted
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