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:   Thu, 15 Jun 2017 16:00:26 +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 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!
>>
>