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

[Dmitry Bakshaev]

2016-09-29 19:52 GMT+04:00 Pierre Delaage <delaage.pierre at free.fr>:
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.

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-windows-7
administrator may set "System variables" globally,
regular user may set only "User variables".
also from


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


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


> 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
>
> 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-variables
http://security.stackexchange.com/questions/119962/what-are-some-vulnerabilities-of-environment-variables-on-any-platform
http://breakingmalware.com/vulnerabilities/elastic-boundaries-elevating-privileges-by-environment-variables-expansion/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20161220/79060bdd/attachment.html>