--cafile enabling system-trust nevertheless?

[Daniel Lenski]

On Sat, Sep 7, 2024 at 2:19 AM David Woodhouse <dwmw2 at infradead.org> wrote:
> > - What you're seeing here is the tunnel/data phase, running in the
> > `openconnect` process (as a privileged user).
>
> No, NetworkManager runs openconnect as an *unprivileged* user. Not
> actually "nobody" but its own "NM-openconnect" version of nobody.
>
> All it can do is open the one /dev/net/tun device which was created for
> it by NetworkManager, and shovel packets back and forth. And send the
> IP configuration back to NetworkManager via D-Bus to be set up.
>
> Running unprivileged in the tunnel phase is a key part of the
> openconnect security model (and it's different to the Cisco crap, which
> runs as root for a lot of things where it really shouldn't).

Thanks, I hadn't realized that NM refines the required privileges of
the openconnect binary down to one tun device plus D-Bus.

> If you run openconnect from the *command* line, then yes it'll need to
> invoke its vpnc-script with CAP_NET_ADMIN in order to configure the
> networking. And CAP_SYS_ADMIN to let it write /etc/resolv.conf. But in
> that model you can still do the *authentication* as your normal user,
> as shown at https://www.infradead.org/openconnect/nonroot.html

Right, that's the unprivileged-for-authentication piece that I was describing.

> (And even then, strictly openconnect itself doesn't need privs; I've
> never experimented much with 'openconnect -s "sudo vpnc-script", and
> I'm not entirely sure there's much point without a lot of focus on
> hardening vpnc-script itself to be a safe entry point.)

I definitely played around with this quite a lot while working on
https://github.com/dlenski/vpn-slice and then actually used it at
$OLDOLDJOB for managing a small herd of simultaneous VPN connections.
If you want the vpnc-script to be able to configure routing and DNS,
it still needs root/CAP_*_ADMIN privileges.