[stunnel-users] Public domain [PATCH] support environment variables in config file

[Sebastian Rose-Indorf]

Hello Michal,

I think it would be a good idea to integrate these Patch into the next version.

Best regards
Sebastian




Von: stunnel-users [mailto:stunnel-users-***@stunnel.org] Im Auftrag von Dmitry Bakshaev
Gesendet: Montag, 23. Mai 2016 14:24
An: stunnel-***@stunnel.org
Betreff: [stunnel-users] Public domain [PATCH] support environment variables in config file

the problem frequently occurs on the client side: admin need to configure stunnel for multiple users.
every user has own key, certificate, own permissions on file system (for log-files, etc)
this patch allow to write flexible config.
some examples:
cert = %USERPROFILE%\.config\my.pem (windows)
cert = ${HOME}/.config/my.pem (other)

output = %APPDATA%\stunnel.log (windows)
output = ${HOME}/stunnel.log (other)
CAfile = %ALLUSERSPROFILE%\ourCAbundle.crt (windows)
CAfile = /etc/ssl/certs/ourCAbundle.crt (other, not using variables)
"secure" :) random port example:
...
[srv1]
accept = 127.0.0.1:%SRV1_PORT% (windows)
accept = 127.0.0.1:${SRV1_PORT} (other)
...
start stunnel (batch-file or shell-script):
set SRV1_PORT=%RANDOM% (windows)
limitations:
1. don't support unicode on windows (localized usernames, files, etc)
2. only ${NAME} syntax supported on *nix (not $NAME).

[Michał Trojnara]

I'm pretty sure the use of ExpandEnvironmentStringsA() will break WCE
builds. Please correct me if I'm wrong.

Best regards,
Mike

Post by Sebastian Rose-Indorf
the problem frequently occurs on the client side: admin need to
configure stunnel for multiple users.
every user has own key, certificate, own permissions on file system (for
log-files, etc)
this patch allow to write flexible config.
cert = %USERPROFILE%\.config\my.pem (windows)
cert = ${HOME}/.config/my.pem (other)
output = %APPDATA%\stunnel.log (windows)
output = ${HOME}/stunnel.log (other)
CAfile = %ALLUSERSPROFILE%\ourCAbundle.crt (windows)
CAfile = /etc/ssl/certs/ourCAbundle.crt (other, not using variables)
...
[srv1]
accept = 127.0.0.1:%SRV1_PORT% (windows)
accept = 127.0.0.1:${SRV1_PORT} (other)
...
set SRV1_PORT=%RANDOM% (windows)
1. don't support unicode on windows (localized usernames, files, etc)
2. only ${NAME} syntax supported on *nix (not $NAME).
_______________________________________________
stunnel-users mailing list
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

[Dmitry Bakshaev]

yes, patch not applicable to WCE.

WCE don't support environment variables, other projects try to emulate it:
https://bugzilla.mozilla.org/show_bug.cgi?id=465874 (through command line)
http://pocoproject.org/docs-1.5.1/99200-WinCEPlatformNotes.html#3
(hardcoded)

attached new version of patch with disabled feature on WCE platform.

Post by Michał Trojnara
I'm pretty sure the use of ExpandEnvironmentStringsA() will break WCE
builds. Please correct me if I'm wrong.

[Pierre Delaage]

Hi Michal,
Did not have a look at the code yet, but should it be possible to
replace envvars usage by some keys in the registry on windows platform
and/or %userprofile%/config-file ?

Anyway, my opinion on the patch is that there is no real interest for
"generic/self-expanding" config file , and it is even dangerous :
I would not trust stunnel if, at run time, its config could be modified
by USER envvars...

I would rather prefer "usual config file" BUT stored (and then read by
sw) in USERPROFILE (on WCE : there is only ONE profile, so that we can
easily create fake stubs for w32 functions),
and then use the stunnel command line to load the proper config, or
whatever admin system script invoking stunnel program.

Moreover if one needs a specific admin mechanism to CREATE
"personalized" config file based on a common template, this can be done
easily by some system scripting either in linux or windows. Personnaly I
am making a wide usage of sed (even with gnuwin32 : remember, sed is
able to access system variables).
This is NOT directly an stunnel issue, but a pure admin issue.

NB: if stunnel is running as a service, there is no reason that ordinary
users modify the config with "customized options" : so if one cert is
needed, its name can be hardcoded in the config file.
if the cert need to be changes, one can play with the cert file (by
admin scripting if necessary).

Yours sincerely,
Pierre

Post by Michał Trojnara
I'm pretty sure the use of ExpandEnvironmentStringsA() will break WCE
builds. Please correct me if I'm wrong.
Best regards,
Mike

Post by Sebastian Rose-Indorf
the problem frequently occurs on the client side: admin need to
configure stunnel for multiple users.
every user has own key, certificate, own permissions on file system (for
log-files, etc)
this patch allow to write flexible config.
cert = %USERPROFILE%\.config\my.pem (windows)
cert = ${HOME}/.config/my.pem (other)
output = %APPDATA%\stunnel.log (windows)
output = ${HOME}/stunnel.log (other)
CAfile = %ALLUSERSPROFILE%\ourCAbundle.crt (windows)
CAfile = /etc/ssl/certs/ourCAbundle.crt (other, not using variables)
...
[srv1]
accept = 127.0.0.1:%SRV1_PORT% (windows)
accept = 127.0.0.1:${SRV1_PORT} (other)
...
set SRV1_PORT=%RANDOM% (windows)
1. don't support unicode on windows (localized usernames, files, etc)
2. only ${NAME} syntax supported on *nix (not $NAME).
_______________________________________________
stunnel-users mailing list
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

_______________________________________________
stunnel-users mailing list
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

[Dmitry Bakshaev]

Did not have a look at the code yet, but should it be possible to replace
envvars usage by some keys in the registry on windows platform and/or
%userprofile%/config-file ?
Anyway, my opinion on the patch is that there is no real interest for
I would not trust stunnel if, at run time, its config could be modified by
USER envvars...

which difference between %userprofile%/config-file and USER envvars?
both are USER owned and USER controlled.
certificate and keys also USER private data.
and stunnel started by USER owned by USER.
if stunnel started by SYSTEM/ADMIN he uses SYSTEM/ADMIN envvars (if
needed), certs, keys, etc.

global "generic/self-expanding" config file is ADMIN owned.
USER has permissions to substitute some values, restricted by ADMIN.

[Dmitry Bakshaev]

Post by Pierre Delaage
Hi Michal,
Did not have a look at the code yet, but should it be possible to replace
envvars usage by some keys in the registry on windows platform and/or
%userprofile%/config-file ?

why not just start stunnel with config parameter on command line?
stunnel %USERPROFILE%/stunnel-config-file (windows)
stunnel ${HOME}/stunnel-config-file (*nix)

[Pierre Delaage]

Hi,
The difference is that, on WCE, for stunnel code, it is straigthforward
to access the "unique profile" stunnel.conf, WITHOUT in fact dealing
with envvars,
rather than 1/ decode %VARNAME% tokens in conf file and then ask env for
replacement...
well...ok..we can create stubs as well for getenv etc... but is is much
more complicated.

For W32 platforms, communicating with a server with env vars can open
issues.
BUT working in "local user sandbox", folders etc...is more secure than
modifying system files by everyone through envvars.

More generally, I agree that a per user conf can be useful ONLY IF each
user is able, and "directed to" start HIS/HER STUNNEL by HAND, in a user
space process.

But to achieve this....stunnel is ALREADY ready to go by using the
command line like this "stunnel myownconfig.conf", of course having "my"
own copy of stunnel executable.

So there is no real need to have an embeddef feature in stunnel for conf
file customization per user.

And, once again, as conf file are just "text files", it is quite easy to
create a bunch of such from a template, by text editiong tools : sed on
win32 is really powerful, or win32 perl engine, or whatever scripting
language you prefer.

Yours sincerely,
Pierre

Post by Pierre Delaage
Did not have a look at the code yet, but should it be possible to
replace envvars usage by some keys in the registry on windows
platform and/or %userprofile%/config-file ?
Anyway, my opinion on the patch is that there is no real interest
I would not trust stunnel if, at run time, its config could be
modified by USER envvars...
which difference between %userprofile%/config-file and USER envvars?
both are USER owned and USER controlled.
certificate and keys also USER private data.
and stunnel started by USER owned by USER.
if stunnel started by SYSTEM/ADMIN he uses SYSTEM/ADMIN envvars (if
needed), certs, keys, etc.
global "generic/self-expanding" config file is ADMIN owned.
USER has permissions to substitute some values, restricted by ADMIN.

[Pierre Delaage]

yes ! sure !
simple and efficient.

Post by Pierre Delaage
Hi Michal,
Did not have a look at the code yet, but should it be possible to
replace envvars usage by some keys in the registry on windows
platform and/or %userprofile%/config-file ?
why not just start stunnel with config parameter on command line?
stunnel %USERPROFILE%/stunnel-config-file (windows)
stunnel ${HOME}/stunnel-config-file (*nix)

[Dmitry Bakshaev]

Hi,
The difference is that, on WCE, for stunnel code, it is straigthforward to
access the "unique profile" stunnel.conf, WITHOUT in fact dealing with
envvars,
rather than 1/ decode %VARNAME% tokens in conf file and then ask env for
replacement...
well...ok..we can create stubs as well for getenv etc... but is is much
more complicated.

"environment expanded config" feature is designed for the platform that
support it - on WCE is not avialable - config is static text file,
and use static values in config files on other platform not prohibited :
ADMIN chooses which
parameters USER can expand to USER own values or none.

For W32 platforms, communicating with a server with env vars can open
issues.

example, please. every account that start stunnel has his own environment,
cert, key, etc.

BUT working in "local user sandbox", folders etc...is more secure than
modifying system files by everyone through envvars.

files not modified globally, only for current USER by USER values in
runtime, only for specified parameters

More generally, I agree that a per user conf can be useful ONLY IF each

user is able, and "directed to" start HIS/HER STUNNEL by HAND, in a user
space process.

yes. one of our scenarios.

But to achieve this....stunnel is ALREADY ready to go by using the command
line like this "stunnel myownconfig.conf", of course having "my" own copy
of stunnel executable.
So there is no real need to have an embeddef feature in stunnel for conf
file customization per user.
And, once again, as conf file are just "text files", it is quite easy to
create a bunch of such from a template, by text editiong tools : sed on
win32 is really powerful, or win32 perl engine, or whatever scripting
language you prefer

this feature makes it unnecessary to copy config to every user and edit
files manually or using sed/perl.
not need ADMIN intervention after adding new USER.
adding/replace service/port not need regenerate all users config - one
centralized config.
this is the primary purpose - ADMIN make one config as template for all
users.

for example server scenario: we has multiple stunnel instanses on gentoo
linux
and i can configure on template:
output = /var/log/stunnel/stunnel_${SVCNAME}.log
each instance has its own log. (SVCNAME variable contains instance name
from init.d startup scripts)

[Pierre Delaage]

Hello,
To my mind, admin tasks such as conf file customization, should be
performed by admin scripts, not app running in admin mode.

With *GnuWin32 *sed AND echo commands, things are really simple :

*stunnel.conf :**
*

cert = %USERPROFILE%\.config\my.pem (windows)

output = %APPDATA%\stunnel.log (windows)


*script "envsed.bat" on Windows :**
*

cat stunnel.conf | ^

sed -r -e "s/^(.*)$/C\:\\Progra~2\\GnuWin32\\bin\\echo.EXE \1/e"


every envvar "à la windows" is expanded ....
Will work the same in Linux.

If we really modify stunnel to do that job, I recommend to (try to) use
stubs for WCE trying to keep one main code, and keeping an acceptable
behavior in WCE,
instead of playing with #if WCE #else etc ...

Another way to proceed is that stunnel recognizes a very small set of
"pseudo-envvars", like eg we can find in samba conf files,
such as, eg, %u for current user home folder, and that it expands (or
"translate") internally with its own logic (of course using system calls
if needed),
but in any case, stunnel has to do some work for tokenization, something
that I think dangerous :
it would not be good that stunnel expands ANY envvar, known or UNKNOWN,
without being able to predict the effects on its execution.
Moreover, envars can be modified on the fly in an unpredictable way:
what if stunnel reloads the conf after an envvar change ?
if it even does NOT detect the change, there may be issues ...and if it
detects the change and reloads, there may be other issues...

Anyway, for the purpose of having multiple stunnel processes, running in
user space, started from USER command line, it does not appear clear to
me why an admin should create the USER conf files...the USER should be
aware of what is he/she doing with stunnel?
and it is not clear why and HOW multiple users, logged-on on the ?same?
machine, each working in USER SPACE, should run stunnel simultaneously ...

Question is also : if stunnel is running as a service, how will it deal
with conf file containing ENVVARS, and what interest for this as
system-wide stunnel just need one unique conf file.

Yours sincerely,
Pierre

Post by Pierre Delaage
Hi,
The difference is that, on WCE, for stunnel code, it is
straigthforward to access the "unique profile" stunnel.conf,
WITHOUT in fact dealing with envvars,
rather than 1/ decode %VARNAME% tokens in conf file and then ask
env for replacement...
well...ok..we can create stubs as well for getenv etc... but is is
much more complicated.
"environment expanded config" feature is designed for the platform
that support it - on WCE is not avialable - config is static text file,
and use static values in config files on other platform not prohibited
: ADMIN chooses which
parameters USER can expand to USER own values or none.
For W32 platforms, communicating with a server with env vars can
open issues.
example, please. every account that start stunnel has his own
environment, cert, key, etc.
BUT working in "local user sandbox", folders etc...is more secure
than modifying system files by everyone through envvars.
files not modified globally, only for current USER by USER values in
runtime, only for specified parameters
More generally, I agree that a per user conf can be useful ONLY IF
each user is able, and "directed to" start HIS/HER STUNNEL by
HAND, in a user space process.
yes. one of our scenarios.
But to achieve this....stunnel is ALREADY ready to go by using the
command line like this "stunnel myownconfig.conf", of course
having "my" own copy of stunnel executable.
So there is no real need to have an embeddef feature in stunnel
for conf file customization per user.
And, once again, as conf file are just "text files", it is quite
easy to create a bunch of such from a template, by text editiong
tools : sed on win32 is really powerful, or win32 perl engine, or
whatever scripting language you prefer
this feature makes it unnecessary to copy config to every user and
edit files manually or using sed/perl.
not need ADMIN intervention after adding new USER.
adding/replace service/port not need regenerate all users config - one
centralized config.
this is the primary purpose - ADMIN make one config as template for
all users.
for example server scenario: we has multiple stunnel instanses on
gentoo linux
output = /var/log/stunnel/stunnel_${SVCNAME}.log
each instance has its own log. (SVCNAME variable contains instance
name from init.d startup scripts)