Hi,
On Mon, 15 Aug 2022 at 12:50, Gert Doering <g...@greenie.muc.de> wrote:
> On Mon, Aug 15, 2022 at 12:40:55PM +0200, Timo Rothenpieler wrote:
> > or don't even try to retain capabilities, since
> > they're not needed either way. I'd prefer the later, since fewer
> > capabilities is generally better.
>
> I could see arguments for "we want to do the ifconfig/route setup in
> an --up script" - for example to do VRF/NetNS stuff that OpenVPN can not
> do itself. So for these scenarios having the capability around would
> be useful (= thus, try-and-warn)...
>
> Different scenario, same options. We don't always know what users want.
Let me just second the "fewer capabilities is generally better"
argument. CAP_NET_ADMIN is a broad set of effective capabilties and
has been a popular path for privilege escalation vulnerabilities in
the past. See for example these two recent CVEs:
CVE-2022-2586
A use-after-free in the Netfilter subsystem may result in local
privilege escalation for a user with the CAP_NET_ADMIN capability in
any user or network namespace.
CVE-2022-2588
Zhenpeng Lin discovered a use-after-free flaw in the cls_route
filter implementation which may result in local privilege escalation
for a user with the CAP_NET_ADMIN capability in any user or network
namespace.
So I'm really not in favour of retaining CAP_NET_ADMIN "just in case".
I would even like to be able to not retain it at all.
-Steffan
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
