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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Jun 2017 15:04:10 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Julien Gomes <julien@...sta.com>, davem@...emloft.net
Cc:     Netdev <netdev@...r.kernel.org>,
        Donald Sharp <sharpd@...ulusnetworks.com>
Subject: Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on
 cache reports

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