openssh unix dev - Mar 2004 - extra groups passed by openssh - security issue?

I would appreciate your opinion on a problem with sshd on Linux,
when running under daemontools supervise.

The configuration:
sshd version OpenSSH_3.7.1p2
Redhat Linux 2.4.20-8smp #1 SMP  i686
supervise / daemontools-0.76

I see the following behavior regarding groups:
-bash-2.05b$ ssh mschulz at localhost id -Gn
id: cannot find name for group ID 201
id: cannot find name for group ID 2039
OA3  201 2039

The group my account belongs to is OA3, groups 201 and 2039 do not exist..
(a normal login or su, and 'id -Gn' works as expected)

It turns out that when I run sshd standalone (debug), it works fine - 
only when
run under the supervise command I see the strange extra groups.

This is not related to SSH privilege separation, the install is correct 
and works fine
with respect to the sshd privilege separation user. (I've looked through 
the strace
output).
 
Between different user accounts, the problem occurs often with the exact 
same behavior,
but for some there is only one different extra group ID, or none at all.

Is this a known problem?
Can anyone confirm it?

Looking at the source, it appears that great care is taken to _remove_
all extra groups before starting subprocesses, and indeed  if I look at the
exact same configuration on Solaris 8, there are no extra groups.

Is this a compile option problem?  I have
#define HAVE_SETGROUPS 1
and everything looks proper to me.

Am I looking at a bug or two?
Is there a some unit testing code for the uid and privilege switching 
code I could
run?

Any simple things I should try with supervise?

I am ancious to exclude any security issues related to this issue.

I am relatively reluctant to 'experiment' on this box, as it is our 
company's main CVS server,
making use of groups to control write access.

Thanks a lot.

   Martin

Hi.
	I installed daemontools-0.76 and was not able to reproduce this on my 
box with OpenSSH 3.7.1p2 (RH9, 1 cpu, kernel 2.4.20-30.9).

Martin Schulz wrote:
> I would appreciate your opinion on a problem with sshd on Linux,
> when running under daemontools supervise.
> The configuration:
> sshd version OpenSSH_3.7.1p2
> Redhat Linux 2.4.20-8smp #1 SMP  i686
> supervise / daemontools-0.76
More information is needed:
Did you compile OpenSSH yourself, and if so with what options?
In particular, are you using PAM?
What's your account database (eg do you use NIS?)
Which Redhat release and have any patches been applied?
What is the glibc version?
What does the script starting sshd contain?
> I see the following behavior regarding groups:
> -bash-2.05b$ ssh mschulz at localhost id -Gn
> id: cannot find name for group ID 201
> id: cannot find name for group ID 2039
> OA3  201 2039
 >
> The group my account belongs to is OA3, groups 201 and 2039 do not exist..
> (a normal login or su, and 'id -Gn' works as expected)
What about running, eg, inetd/telnetd under daemontools?
> It turns out that when I run sshd standalone (debug), it works fine - 
> only when run under the supervise command I see the strange extra groups.
To clarify: running sshd as a stand-alone daemon (ie "sshd" with no 
options) *and* with debugging (ie "sshd -ddd") both work correctly?
> This is not related to SSH privilege separation, the install is correct 
> and works fine with respect to the sshd privilege separation user.
(I've
 > looked through the strace output).
> 
> Between different user accounts, the problem occurs often with the exact 
> same behavior,
> but for some there is only one different extra group ID, or none at all.
You always get the same behaviour with the same accounts?  What do the 
users exhibiting these symptoms have in common?  Do those groups exist 
in /etc/group or the gid field of /etc/passwd?
> Is this a known problem?
Not that I know of.

[...]

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.