2016-05-31 17:07 GMT+04:00 Pierre Delaage [email protected]:

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)

2016-06-01 12:29 GMT+04:00 Pierre Delaage [email protected]:

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.

yes. this is primary goal of this patch - do not edit (manually or with sed) config file for each user. if user added/removed, if port/host changed, etc. admin mantains only one config that fit all users.

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 ...

I am not familiar with the Windows CE, first and last time when seen the WinCE-device - the beginning of the 2000s.

point into the right direction if you know. win32 has native ExpandEnvironmentStringsA() function, on other platform used stub/wrapper around getvar() function (#ifndef USE_WIN32). WinCE do not has ExpandEnvironmentStringsA() or getvar(), besause do not has environment variables. #ifndef _WIN32_WCE - simple way to not execute unnecessary code at all, but attached patch version has ExpandEnvironmentStringsA stub for WinCE, please review it.

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.

environment variables values owned by user. only owner or admin cat change it, not any-other user. starting process with admin/system/current_user privileges process inherits admin/system/current_user envvars values. stunnel not expands ANY or UNKNOWN envvars - only those that admin will specified in config file.

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...

if running process not modify envvars by himself

ExpandEnvironmentStrings/getvar expands to values taken on process start.

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?

admin manages stunnel and applications configuration on server and client side: hosts, ports, other stunnel options. user has own private certificate used with stunnel and works with applications through 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 ...

not necessary simultaneously - stunnel may use same ports on localhost for all users (from one global config). users alternately starts his own stunnel process with own certificate (path expanded from one global config).

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.

on server or client side?

for example on server with miltiple stunnel instances for create predictable log files names (without manually editing): output = /var/log/stunnel/stunnel_${SVCNAME}.log

Hi Dmitry, I reviewed our previous discussion on setting up stunnel by envvars...

On WCE, if you really want to have a unic code to manage envvars... well ok, you have to write a stub for ExpandEnvironmentStrings, that either performs %XX% replacement from predefined values OR reads those values from a wce-specific "pseudo-env-txtfile".

As there is only ONE user in WCE, it is quite straightforward to write such stub, that will be universal for any wce terminal: the predefined values can be identical for any wce terminal.

NB : I already mentioned that (re)configuring stunnel through envars is not safe, at least on Win32 platforms: on those systems, env vars are stored in the registry (and synchronised with specific system calls): every malicious sw that can hack the registry can change env vars, it is of course very easy in we use "user" env vars, not system env vars.

Yours sincerelly, Pierre

Le 10/09/2016 09:40, Dmitry Bakshaev a écrit :

we used patched version on many workstantions (linux and windows) and found that this feature allows to flexibly and automatically manage the stunnel configuration on the workstations.

environment variables like $HOME, %USERNAME% and others defined once and never changed, that does not affect stunnel restart and configuration reload. but it allows us to have a single configuration for all users.

the only question that remains: how to use this feature where there is no environment variables (WinCE, which we do not have). may by ExpandEnvironmentStringsA stub specifically for WinCE? any comments, Pierre?

2016-07-07 15:42 GMT+04:00 Dmitry Bakshaev <[email protected] mailto:[email protected]>:

2016-06-01 12:29 GMT+04:00 Pierre Delaage <[email protected]
<mailto:[email protected]>>:

    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. 

yes. this is primary goal of this patch - do not edit (manually or
with sed) config file for each user.
if user added/removed, if port/host changed, etc.
admin mantains only one config that fit all users.

    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 ... 

I am not familiar with the Windows CE, first and last time when
seen the WinCE-device - the beginning of the 2000s. point into the
right direction if you know.
win32 has native ExpandEnvironmentStringsA() function,
on other platform used stub/wrapper around getvar() function
(#ifndef USE_WIN32).
WinCE do not has ExpandEnvironmentStringsA() or getvar(), besause
do not has environment variables.
#ifndef _WIN32_WCE - simple way to not execute unnecessary code at
all,
but attached patch version has ExpandEnvironmentStringsA stub for
WinCE, please review it.

    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. 

environment variables values owned by user. only owner or admin
cat change it, not any-other user.
starting process with admin/system/current_user privileges process
inherits admin/system/current_user envvars values. stunnel not
expands ANY or UNKNOWN envvars - only those that admin will
specified in config file.

    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... 

if running process not modify envvars by himself
ExpandEnvironmentStrings/getvar expands to values taken on process
start.

    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? 

admin manages stunnel and applications configuration on server and
client side: hosts, ports, other stunnel options.
user has own private certificate used with stunnel and works with
applications through 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 ... 

not necessary simultaneously - stunnel may use same ports on
localhost for all users (from one global config).
users alternately starts his own stunnel process with own
certificate (path expanded from one global config).

    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.

on server or client side? for example on server with miltiple
stunnel instances for create predictable log files names (without
manually editing): output = /var/log/stunnel/stunnel_${SVCNAME}.log

Hi Dmitry, Shortly speaking : per user envvars are meaningless for WCE ..phones, as there is no way to switch from a user to another on those devices. At a time WCE was used on "handeld PC", where things could be slightly different. So I recommend that, when your customized stunnel is loading conf file, and after you have "tokenized" the file to get env-vars name, you mimic system calls with a stub that always return the same values RELATIVE to "." folder, ie where the stunnel executable has been installed on the phone. This is the SOLE path that is reliable on a WCE phone.

Clearly, your envars will be "path to something" I guess : typically path to the cert file. for this example your cert file on a phone will always be in "./mycert.crt".

For a win32 platform, there will be either a system wide stunnel running (so who will set up envvars to give to the stunnel env ? another system script ? with the risk that this script be modified by malicious code ?), or a "one user at a time"- wide stunnel running : it will not be possible to get many processes running stunnel at the same time (just because, whatever envvar you use, all your processes may conflict when listening to "accept" sockets) unless ... you customize "accept" port through envvars ? for me this is quite dangerous : customizing accept or -even more dangerous- connect ports through envars is really easy in user space for any malicious code (to redirect the trafic..). So I still do not see clearly the interest for stunnel to decode envvars on the fly in conf file.

If you are looking for conf file automated generation on large sites, I already gave the trick in a 1-line sed command :

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

You may argue that this trick can lead to same security breach than explained above ...but ... NOT for system-wide stunnel for which -normally- the stunnel.conf file can NOT be modified. Even for system-wide stunnel, any malicious sw that can tweak the system registry will be able to redirect stunnel trafic... So this is why I do not encourage this patch.

Apart from that, technically speaking, you can go forward by creating a stub for getenv or expandstring w32 functions.

To setup a wce dev environment, see this page : http://delaage.pierre.free.fr The link for evc4 is now broken : use this instead : http://download.microsoft.com/download/C/3/F/C3F8B58B-9753-4C2E-8B96-2DFE347...

I will refresh this web page later with more recent stunnel codebase.

Yours sincerely Pierre

Le 28/09/2016 20:26, Dmitry Bakshaev a écrit :

Hello Pierre!

2016-09-10 14:00 GMT+04:00 Pierre Delaage <[email protected] mailto:[email protected]>:

Hi Dmitry,
I reviewed our previous discussion on setting up stunnel by envvars...

On WCE, if you really want to have a unic code to manage envvars...
well ok, you have to write a stub for ExpandEnvironmentStrings,
that either performs %XX% replacement from predefined values OR
reads those values from a wce-specific "pseudo-env-txtfile".

https://msdn.microsoft.com/en-us/library/ee490554(v=winembedded.60).aspx https://msdn.microsoft.com/en-us/library/ee490554%28v=winembedded.60%29.aspx registry values under: [HKEY_LOCAL_MACHINE\init\BootVars] "name" = "value" it's like "global","system","shared".

2. https://msdn.microsoft.com/en-us/library/aa453706.aspx

https://msdn.microsoft.com/en-us/library/aa516912.aspx it's way to emulate : getenv("APPDATA"); getenv("USERNAME"); .... something like (pseudocode): if( !strcmp(name, "APPDATA") ){ SHGetSpecialFolderLocation(NULL, CSIDL_APPDATA, ...); ...get "value"... } else if(!strcmp(name, "USERNAME")){ GetUserNameEx(NameWindowsCeLocal ...) ...get "value"... } else ...

yes, syntax for "variables" must be %XX% - same as on windows. I think is not necessary to substitute the contents of the config file ("pseudo-env-txtfile") to another config file (stunnel.conf).

As there is only ONE user in WCE, it is quite straightforward to
write such stub, that will be universal for any wce terminal:
 the predefined values can be identical for any wce terminal.

I am not familiar with WCE developlemt tools. I read about it: http://stackoverflow.com/questions/3463420/how-to-create-applications-for-wi... https://en.wikipedia.org/wiki/Windows_CE#Development_tools https://www.microsoft.com/en-us/download/details.aspx?id=17284 https://msdn.microsoft.com/en-us/library/ms905342.aspx INSTALL.WCE makew32.bat and completely puzzled by the number of versions, variants & etc. also I do not have the experience, tools and devices for building and testing WCE apps.

currently patch done for win32 (using native ExpandEnvironmentStringsA) and *nix (ExpandEnvironmentStringsA stub), it's tested and worked.

NB : I already mentioned that (re)configuring stunnel through
envars is not safe, at least on Win32 platforms:
on those systems, env vars are stored in the registry (and
synchronised with specific system calls): every malicious sw that
can hack the registry can change env vars, it is of course very
easy in we use "user" env vars, not system env vars.

"user" env vars values has no effect on "system" env vars. to change "system"/"other user" env vars admin/owner privileges required.

Hi Dmitry, Please see answers below... Yours sincerely, Pierre

Le 20/12/2016 19:21, Dmitry Bakshaev a écrit :

2016-09-29 19:52 GMT+04:00 Pierre Delaage <[email protected] mailto:[email protected]>: Hi Pierre

Shortly speaking : per user envvars are meaningless for WCE
..phones, as there is no way to switch from a user to another on
those devices. At a time WCE was used on "handeld PC", where
things could be slightly different.
So I recommend that, when your customized stunnel is loading conf
file, and after you have "tokenized" the file to get env-vars name,
you mimic system calls with a stub that always return the same
values RELATIVE to "." folder,
 ie where the stunnel executable has been installed on the phone.
This is the SOLE path that is reliable on a WCE phone.

Clearly, your envars will be "path to something" I guess :
typically path to the cert file.
for this example your cert file on a phone will always be in
"./mycert.crt".

1. again from beginning:

different OS has different rules, different filename syntax: /home/... /etc/... "C:\Document and Settings", "C:\Users", different environment variables: "USER" on *nix, "USERNAME" on windows or none on others like WinCE, stunnel has platform specific options: chroot=, setuid=, setgid=, pid= ...

we not target for "one config file for all users in the world", we target "one config file for all users on this system", and config may use (not necessary) these platform specific features or not. for example WinCE may be only specified directly: cert = ./mycert.crt on Windows through USERPROFILE: cert = %USERPROFILE%.certs\my.p12 or directly (in personal config file) cert = "c:\Users\john\Desktop\New Folder\my.p12" on *nix through HOME: cert = ${HOME}/.certs/my.p12

For a win32 platform, there will be either a system wide stunnel
running (so who will set up envvars to give to the stunnel env ?

2. only the necessary and known variables substituted in the

configuration file, other values specified as usual.

There were 2 questions in 1 on my side, and you answered only on the conf file part, so I repeat my question : on a win32 system, in your plans, will there be ONE system-wide stunnel running (so that per-user envvar customization is useless), or do you plan to have "multiple" stunnel running simultaneously ? (something quite strange unless you customize every ip and/or ports in stunnel conf...but why?) or ... just one stunnel process running, for THE whole system, for the currently logged-in user ? (in that case, if THE user is starting stunnel, one conf file installed with stunnel, and remotely managed by the admin, can be enough; and if the pb is to get access to a personal cert file, a generic "./" path into the conf file is enough).

another system script ?

3. no. standard way to set envvars from Windows GUI (for example, from

Google): https://www.nextofwindows.com/how-to-addedit-environment-variables-in-window... administrator may set "System variables" globally, regular user may set only "User variables". also from

This is not the only way to set envvars; registry hacks can ALSO do the job, particularly from malicious code...

with the risk that this script be modified by malicious code ?),

or a "one user at a time"- wide stunnel running : it will not be
possible to get many processes running stunnel at the same time
(just because, whatever envvar you use, all your processes may
conflict when listening to "accept" sockets) unless ... you
customize "accept" port through envvars ?
for me this is quite dangerous : customizing accept or -even more
dangerous- connect ports through envars is really easy in user
space for any malicious code (to redirect the trafic..).

4. the administrator decides which of the configuration parameters can

be changed by substituting the values of the environment variables, choosing between security and management flexibility: from nothing to customize "accept" port through envvars, if it is required.

So I still do not see clearly the interest for stunnel to decode
envvars on the fly in conf file.

If you are looking for conf file automated generation on large
sites, I already gave the trick in a 1-line sed command :

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

5. if machine joined into domain, administrator adds new user into AD,

we need manually update/generate new config files? run it from Group Policy? also we need regenarete all config files on changing stunnel_template.conf? by substituting variables is not necessarily - only one shared config file, centrally managed by the administrator.

At a time or another, if you are running in an AD environment, users will login and execute some script downloaded from the server. Refreshing their conf file at that time is like updating any other setting or sw in the system. In any case updating stunnel-conf--template will require a new download of the template on client systems.

You may argue that this trick can lead to same security breach
than explained above ...but ... NOT for system-wide stunnel for
which -normally- the stunnel.conf file can NOT be modified. Even
for system-wide stunnel, any malicious sw that can tweak the
system registry will be able to redirect stunnel trafic... 

6. if we need static system-wide stunnel.conf, we simple write it

without envvars. exactly the same as it is now.

So this is why I do not encourage this patch. 

7. I think that the discussion about "hack regisrtry", "malicious sw",

etc. should be considered in the context of the overall security of the Windows operating system, not stunnel context. "by disign" any multiuser operating system has "user privileges separation" for user files, processes, and other objects, like Windows registry, environment variables &etc. regular user is not allowed to modify objects of other users. when start user session with other credentials through "sudo" on *nix/"run as" on windows, system "reset" environment and build it from scratch, merging default "System variables" with "User variables" of the new user. on Windows services start under SYSTEM account ("local system" , "LocalSystem" ...), which has own profile, registry branch, environment variables. only administrator may change their.

The main pb is that : 1/ system envvars can be overiden in user context : and it is quite straightforward in _user _context to ... modify _user _variable overiding system variables... by any software (malicious or not) (https://support.microsoft.com/en-us/kb/100843) 2/ As user can modify THEIR envvars, how an admin can be sure that stunnel per-user conf file is working as expected (by the admin...) 3/ per user conf file in a system means that stunnel is NOT running as a system wide process, but as a per-user process (probably in foreground) : so that one user (or malicious code) can easily stop it, modify conf file or restart stunnel with another one. In that case, all the work on the template can be circumvented. So, for all that reasons, and considering that your goal can be achieved differently (sed and/or generic relative path etc...), I am still reserved on the patch. Clearly it allows one to modify stunnel conf on the fly, for a sw that most of the time is used as a service and should not see its conf modified at all. It is lowering the security of stunnel (by lowering, not to say suppressing, its conf file integrity) and the system.

Apart from that, technically speaking, you can go forward by
creating a stub for getenv or expandstring w32 functions. To setup
a wce dev environment, see this page :
http://delaage.pierre.free.fr The link for evc4 is now broken  :
use this instead :
http://download.microsoft.com/download/C/3/F/C3F8B58B-9753-4C2E-8B96-2DFE3476A2F7/eVC4.exe
<http://download.microsoft.com/download/C/3/F/C3F8B58B-9753-4C2E-8B96-2DFE3476A2F7/eVC4.exe>
I will refresh this web page later with more recent stunnel codebase. 

8. referring to p.1 we do not need to "emulate" envvars on platform

that not has it. the last version of the patch has already implemented empty stub for ExpandEnvironmentStrings function on WinCE platform. p.s.: some interresting links about envvars: http://stackoverflow.com/questions/10090014/can-i-trust-my-environment-varia...

http://security.stackexchange.com/questions/119962/what-are-some-vulnerabili...

http://breakingmalware.com/vulnerabilities/elastic-boundaries-elevating-priv...