netdev - NETLINK_ROUTE policy routing questions

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>] [day] [month] [year] [list]

Date:   Tue, 19 Jun 2018 14:17:19 +0000
From:   "Cunningham, Joel" <Joel.Cunningham@...min.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Daniel Wagner <wagi@...om.org>,
        "connman@...ts.01.org" <connman@...ts.01.org>
Subject: NETLINK_ROUTE policy routing questions

Hi,

I've been working through an issue with Connman and NETLINK_ROUTE messages as it relates to policy routing.  Background can be seen here: https://lists.01.org/pipermail/connman/2018-June/022846.html

I'm using kernel 4.9.27 from ASOP releases and had a couple of questions of how NETLINK_ROUTE is intended to work and whether or not we are seeing a kernel bug.

Connman has long-running NETLINK_ROUTE socket which binds with:

memset(&addr, 0, sizeof(addr));
addr.nl_family = AF_NETLINK;
addr.nl_groups = RTMGRP_LINK | RTMGRP_IPV4_IFADDR | RTMGRP_IPV4_ROUTE |
		RTMGRP_IPV6_IFADDR | RTMGRP_IPV6_ROUTE |
		(1<<(RTNLGRP_ND_USEROPT-1));

Connman also creates other short-lived NETLINK_ROUTE sockets to perform setters, in particular, we have RTM_NEWROUTE and RTM_DELROUTE with a custom routing table.  Connman uses policy routing to create a session based routing table.  When a new interface comes online and has a gateway, Connman adds a default route to a new custom routing table.  When this happens, we get a RTM_NEWROUTE message for the main table (254), but we never receive any RTM_NEWROUTE/RTM_DELROUTE messages for our custom table.  Should NETLINK_ROUTE sockets bound to RTMGRP_IPV4_ROUTE be receiving updates for custom tables or only table ID < 256?

The other behavior which I ran into was originally my kernel didn't have CONFIG_IP_MULTIPLE_TABLES enabled and when Connman sent RTM_NEWROUTE/DELROUTE with the custom table, we got NETLINK_ROUTE messages for these actions being applied to the main table (254).  This was corrected by enabling CONFIG_IP_MULTIPLE_TABLES in the kernel, but I was still just curious if using table 254 was a fallback mechanism rather than the setter returning an error.

Thanks,

Joel