On Wed, 19 Aug 2020, Travis Hayes wrote:
> I?m setting up a Linux machine (CentOS7) and am trying to allow
> tap/tun tunneling.
>
> Our organization?s security policy prohibits root logins. Using
> OpenSSH server 7.4 (as provided by the CentOS repositories) non-root
> users are able to open tunnels as long as the sshd_config has The
> setting UsePrivilegeSeparation=no.
>
> All is well, but I wonder what security risks I am taking by disabling
> the separation.
>
> Also, I would like to update to a more current version of the server
> for security as well as for the SSH_TUNNEL environment variable
> introduced in 7.7, but the UsePrivilegeSeparation option has been
> deprecated and a current version (8.3p) refuses to run with that
> option present in the config file. Removing the option, the ioctl() to
> create the tun/tap interface fails, just like with 7.4.
>
> Now that privilege separation is a requirement, is the only way
> forward to allow root logins and authorize the client users by copying
> their public key into root?s authorized_keys file?
>
> If this is the case, I would be giving up per-user auditing, requiring
> keys instead of password (or PAM-based) authentication, as well as the
> ability to use Match blocks to control which users/groups/hosts are
> allowed to create tunnels and which are allowed normal sessions.
>
> Is this on the roadmap for future consideration?
tun/tap forwarding has always been a bit of a fringe feature and
has never had reliable non-root support. The problem is essentially
that most of the operations required to configure a network interface
are privileged.
A few people have asked for non-root tun forwarding over the years,
but nobody has come forward with a design for how it could work in
practice.
I'd certainly be open to a design that used some sort of plug-in
helper program to do the configuration steps, and let OpenSSH punt
all the decision-making to that :)
-d