linux-kernel - Re: [PATCH net-next v14 17/22] ovpn: implement peer add/get/dump/delete via netlink

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]

Message-ID: <CABAhCOSNRu1QfVr_0Las+dSMsbrVE=HLT6pzqQHODkUTxBi0-Q@mail.gmail.com>
Date: Wed, 11 Dec 2024 20:35:56 +0800
From: Xiao Liang <shaw.leon@...il.com>
To: Antonio Quartulli <antonio@...nvpn.net>
Cc: netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Donald Hunter <donald.hunter@...il.com>, Shuah Khan <shuah@...nel.org>, sd@...asysnail.net, 
	ryazanov.s.a@...il.com, Andrew Lunn <andrew+netdev@...n.ch>, 
	Simon Horman <horms@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v14 17/22] ovpn: implement peer
 add/get/dump/delete via netlink

On Wed, Dec 11, 2024 at 7:30 PM Antonio Quartulli <antonio@...nvpn.net> wrote:
>
> Hi Xiao and thanks for chiming in,
>
> On 11/12/2024 04:08, Xiao Liang wrote:
> > On Mon, Dec 9, 2024 at 6:48 PM Antonio Quartulli <antonio@...nvpn.net> wrote:
> > [...]
> >> +/**
> >> + * ovpn_nl_peer_modify - modify the peer attributes according to the incoming msg
> >> + * @peer: the peer to modify
> >> + * @info: generic netlink info from the user request
> >> + * @attrs: the attributes from the user request
> >> + *
> >> + * Return: a negative error code in case of failure, 0 on success or 1 on
> >> + *        success and the VPN IPs have been modified (requires rehashing in MP
> >> + *        mode)
> >> + */
> >> +static int ovpn_nl_peer_modify(struct ovpn_peer *peer, struct genl_info *info,
> >> +                              struct nlattr **attrs)
> >> +{
> >> +       struct sockaddr_storage ss = {};
> >> +       struct ovpn_socket *ovpn_sock;
> >> +       u32 sockfd, interv, timeout;
> >> +       struct socket *sock = NULL;
> >> +       u8 *local_ip = NULL;
> >> +       bool rehash = false;
> >> +       int ret;
> >> +
> >> +       if (attrs[OVPN_A_PEER_SOCKET]) {
> >
> > Similar to link attributes in other tunnel drivers (e.g. IFLA_GRE_LINK,
> > IFLA_GRE_FWMARK), user-supplied sockets could have sockopts
> > (e.g. oif, fwmark, TOS). Since some of them may affect encapsulation
> > and routing decision, which are supported in datapath? And do we need
> > some validation here?
>
> Thanks for pointing this out.
> At the moment ovpn doesn't expect any specific socket option.
> I haven't investigated how they could be used and what effect they would
> have on the packet processing.
> This is something we may consider later.
>
> At this point, do you still think I should add a check here of some sort?
>

I think some sockopts are important. Especially when oif is a VRF,
the destination can be totally different than using the default routing
table. If we don't support them now, it would be good to deny sockets
with non-default values.

> >
> > [...]
> >> +static int ovpn_nl_send_peer(struct sk_buff *skb, const struct genl_info *info,
> >> +                            const struct ovpn_peer *peer, u32 portid, u32 seq,
> >> +                            int flags)
> >> +{
> >> +       const struct ovpn_bind *bind;
> >> +       struct nlattr *attr;
> >> +       void *hdr;
> >> +
> >> +       hdr = genlmsg_put(skb, portid, seq, &ovpn_nl_family, flags,
> >> +                         OVPN_CMD_PEER_GET);
> >> +       if (!hdr)
> >> +               return -ENOBUFS;
> >> +
> >> +       attr = nla_nest_start(skb, OVPN_A_PEER);
> >> +       if (!attr)
> >> +               goto err;
> >> +
> >> +       if (nla_put_u32(skb, OVPN_A_PEER_ID, peer->id))
> >> +               goto err;
> >> +
> >
> > I think it would be helpful to include the netns ID and supported sockopts
> > of the peer socket in peer info message.
>
> Technically the netns is the same as where the openvpn process in
> userspace is running, because it'll be it to open the socket and pass it
> down to ovpn.

A userspace process could open UDP sockets in one namespace
and the netlink socket in another. And the ovpn link could also be
moved around. At this moment, we can remember the initial netns,
or perhaps link-netns, of the ovpn link, and validate if the socket
is in the same one.

Thanks.

> Therefore I am not sure there is any value in echoing back the netns ID.
> Wouldn't you agree?
>
> Regarding sockopts, as mentioned above, this is somewhat unsupported for
> now, so I Am not sure we have anything to send back.
>
>
> Regards,
>
> --
> Antonio Quartulli
> OpenVPN Inc.
>