Hi,
I recently stumbled on http://mirt.net/pipermail/stunnel-users/2008-May/001977.html which is exactly what I am seeing with version 4.27 of stunnel, namely the daemon is not switching to the setuid/setgid specified in the config before it is spawned.
This means that I get 6 processes, 5 run as root with only one (albeit the one lisenting on the specified sockets) dropping privs to the specified user.
The follow-up response from Mike was:
I'll modify stunnel to delay spawning libwrap processes until privileges are dropped.
and indeed, I find in the Changelog file for version 4.25 the following Bugfixes:
* Bugfixes - Spawning libwrap processes delayed until privileges are dropped.
However, it seems that either this fix either didn't make it in, or it somehow managed to creep its way back out because it is happening in 4.27.
Thanks, micah
Micah Anderson wrote:
I recently stumbled on http://mirt.net/pipermail/stunnel-users/2008-May/001977.html which is exactly what I am seeing with version 4.27 of stunnel, namely the daemon is not switching to the setuid/setgid specified in the config before it is spawned.
This means that I get 6 processes, 5 run as root with only one (albeit the one lisenting on the specified sockets) dropping privs to the specified user.
That's how it was designed. 5 helper processes that only perform libwrap checking do not perform chroot/setuid/setgid. If you don't like it just disable libwrap support:
./configure --disable-libwrap && make clean && make && make install
Best regards, Mike
Michal Trojnara Michal.Trojnara@mirt.net writes:
Micah Anderson wrote:
I recently stumbled on http://mirt.net/pipermail/stunnel-users/2008-May/001977.html which is exactly what I am seeing with version 4.27 of stunnel, namely the daemon is not switching to the setuid/setgid specified in the config before it is spawned.
This means that I get 6 processes, 5 run as root with only one (albeit the one lisenting on the specified sockets) dropping privs to the specified user.
That's how it was designed. 5 helper processes that only perform libwrap checking do not perform chroot/setuid/setgid. If you don't like it just disable libwrap support:
If this is how it was designed, may I ask why you say the following[0], in a direct response to someone else asking this same question:
I'll modify stunnel to delay spawning libwrap processes until privileges are dropped.
and then soon after, you released a version 4.25 of stunnel, with this changelog entry:
* Bugfixes - Spawning libwrap processes delayed until privileges are dropped.
but we do not see the libwrap processes spawned as anything but the privileged user still.
I'm sorry if I am missing something obvious here, and I appreciate your explanation!
thanks for your work on stunnel, micah
0. http://mirt.net/pipermail/stunnel-users/2008-May/001978.html
Micah Anderson wrote:
and then soon after, you released a version 4.25 of stunnel, with this changelog entry:
* Bugfixes - Spawning libwrap processes delayed until privileges are dropped.but we do not see the libwrap processes spawned as anything but the privileged user still.
I'm sorry if I am missing something obvious here, and I appreciate your explanation!
What you're missing is an entry for stunnel 4.26:
- /etc/hosts.allow and /etc/hosts.deny no longer need to be copied
to the chrooted directory, as the libwrap processes are no longer chrooted.
Basically I received some complaints and I decided to withdraw this modification. Chrooting libwrap processes was a bad idea.
Honestly I'm sure libwrap (first released by Wietse Venema in 1990) is *a lot* more mature and secure compared to OpenSSL. In case there are any security vulnerabilities in libwrap, stunnel is the least of our problems...
Mike
-
Micah Anderson -
Michal Trojnara