On Thursday, 15 June 2017 5:47:39 PM AEST Gert Doering wrote:
> Hi,
>
> On Thu, Jun 15, 2017 at 12:50:40PM +1000, Steven Haigh wrote:
> > I'm just trying to figure out if its expected behaviour to have the
> > 'username' set in the environment when using the auth-user-pass-verify
> > script.
>
> The code in question (ssl_verify.c) is older than the involvement of
> any of the currently-active developers... but JJK or Ecrist might know.
>
> Anyway, what the code *says* is:
>
> ssl_verify.c, about line 1095:
>
> verify_user_pass_script(...)
> {
> ...
> /* Set environmental variables prior to calling script */
> if (session->opt->auth_user_pass_verify_script_via_file)
> {
> ... (no setenv here)
> }
> else
> {
> setenv_str(session->opt->es, "username", up->username);
> setenv_str(session->opt->es, "password", up->password);
> }
>
>
> so, yes, that is what it *does* - "username" is only ever set together
> with "password", and that's only setenv'ed if you do not use "via-file".
>
> Now, that is about calling the --verify-auth-user-pass, but I think the
> "es" (environment set) being affected here is the global per-connection
> es (not something local to this function), so that would affect
> --client-connect as well.
>
> [..]
>
> > The auth-user-pass-verify documentation states:
> > If method is set to "via-env", OpenVPN will call script with the
> > environmental variables username and password set to the
> > username/password strings provided by the client. Be aware that this
> > method is insecure on some platforms which make the environment of a
> > process publicly visible to other unprivileged processes.
>
> This "some platforms" actually something we should eventually verify
> and clearly spell-out - because Linux and all recent BSDs do *not* show
> the environment to other unprivileged users.
>
> [..]
>
> > No mention of the username env variable when using via-file - but this
> > gives me the impression that the username should *not* be set in the
> > environment - but it should be in the file.
> >
> > So - bug or feature?
>
> Username and Password are always handled in tandem when talking about
> --auth-user-pass-verify, so "both in environment" or "none of them".
>
> Now, if you use a *plugin* (or the management interface), the code will
> always set both in the es, and delete the password(!) afterwards, leaving
> the username intact...
>
>
> Looking from a given distance, I'd say that this is a bug, and "username"
> should propably be always visible in the es (if present), while password
> should not.
>
>
> If you want to experiment: go to ssl_verify.c, and move the line 1123
> (master) outside the else {} block:
>
> old:
>
> else
> {
> setenv_str(session->opt->es, "username", up->username);
> setenv_str(session->opt->es, "password", up->password);
> }
>
> new:
>
> else
> {
> setenv_str(session->opt->es, "password", up->password);
> }
> setenv_str(session->opt->es, "username", up->username);
>
> ... then it should show up in client-connect as well.
I managed to track this down today.
It seems the pam plugin sets the environment variable. As such, as soon as I
add the following line to the server config, the username variable appears
back in the environment for auth-user-pass-verify:
plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn
After commenting this line out and restarting the daemon, the username env
variable is gone.
That still poses the question, is a plugin supposed to be able to alter the
environment presented to the auth-user-pass-verify script?
If so, should these changes also be in the client-connect script?
If not, the environment might need a reset before the auth-user-pass-verify
script is called?
--
Steven Haigh
📧 net...@crc.id.au 💻 http://www.crc.id.au
📞 +61 (3) 9001 6090 📱 0412 935 897
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
