netdev - Re: [PATCH net-next v11 20/23] ovpn: kill key and notify userspace in case of IV exhaustion

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: <21330449-fab6-4c0b-a155-84c7419adbcb@openvpn.net>
Date: Thu, 14 Nov 2024 11:38:51 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: 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>, ryazanov.s.a@...il.com,
 Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v11 20/23] ovpn: kill key and notify userspace in
 case of IV exhaustion

On 13/11/2024 15:28, Sabrina Dubroca wrote:
> 2024-11-12, 16:44:09 +0100, Antonio Quartulli wrote:
>> On 05/11/2024 11:33, Sabrina Dubroca wrote:
>>> 2024-10-29, 11:47:33 +0100, Antonio Quartulli wrote:
>>>> +int ovpn_nl_key_swap_notify(struct ovpn_peer *peer, u8 key_id)
>>>> +{
>>> [...]
>>>> +
>>>> +	nla_nest_end(msg, k_attr);
>>>> +	genlmsg_end(msg, hdr);
>>>> +
>>>> +	genlmsg_multicast_netns(&ovpn_nl_family, dev_net(peer->ovpn->dev), msg,
>>>> +				0, OVPN_NLGRP_PEERS, GFP_ATOMIC);
>>>> +
>>>
>>> Is openvpn meant to support moving the device to a different netns? In
>>> that case I'm not sure the netns the ovpn netdevice is in is the right
>>> one, the userspace client will be in the encap socket's netns instead
>>> of the netdevice's?
>>>
>>> (same thing in the next patch)
>>
>> Well, moving between netns's may not be among the most common use cases, but
>> I can see people doing all kind of weird things, if not forbidden.
> 
> The idea would be that only the ovpn device is in one particular
> netns, so that no packets can make it out of that netns unencrypted. I
> don't know if anybody actually does that.

Well I can imagine starting openvpn in the main netns and moving the 
device afterwards to something more restrictive (i.e. even a docker 
specific netns).

> 
>> Hence, I would not assume the netdevice to always stay in the same netns all
>> time long.
>>
>> This said, what you say assumes that the userspace process won't change
>> netns after having added the peer.
> 
> That shouldn't matter as long as it's still listening to multicast
> messages in the original netns.

Oky.

> 
> Around that same "which netns" question, ovpn_udp{4,6}_output uses the
> socket's, but ovpn_nexthop_from_rt{4,6} uses the netdev's.

I think this is ok, because routing related decision should be taken in 
the netns where the device is, but the transport layer should make 
decisions based on where the socket lives.

Regards,

> 

-- 
Antonio Quartulli
OpenVPN Inc.