secure passwd.adjunct + pam + not set uid root binaries are not able to verify passwords - why?

secure passwd.adjunct + pam + not set uid root binaries are not able to verify passwords - why?

Post by Thomas Glanzman » Wed, 22 May 2002 22:31:41



Hi out there,
we have a secure nis map passwd.adjunct.byname and password files like this line
sithglan:##sithglan:31401:30003:Thomas Glanzmann, CIP Admin:/home/cip/adm/sithglan:/local/login/bin/env-csh

Now we have a problem ... we have some PAM applications which have to verify a
password and should not be set user id root ... but that does not work.

We compiled them with pam support. But they still need set user id root. What
can we do else?

Under Linux it works without the set user id sbit.

The same problem exists for dtaction.

Greetings,
--
Thomas Glanzmann            +49 1212 5 269 38 260
Rathsbergerstrasse 28 D-91054 Erlangen / Burgberg

 
 
 

secure passwd.adjunct + pam + not set uid root binaries are not able to verify passwords - why?

Post by Doug McIntyr » Wed, 22 May 2002 23:08:49



>we have a secure nis map passwd.adjunct.byname and password files like this line
>sithglan:##sithglan:31401:30003:Thomas Glanzmann, CIP Admin:/home/cip/adm/sithglan:/local/login/bin/env-csh
>Now we have a problem ... we have some PAM applications which have to verify a
>password and should not be set user id root ... but that does not work.
>We compiled them with pam support. But they still need set user id root. What
>can we do else?
>Under Linux it works without the set user id sbit.

Hmm I thought Linux implemented the same security action in their NIS
client library long ago.

The NIS server is requiring the client to have root priv's in order to
protect the shadow password data from prying eyes. If anybody could
access the passwd.adjunct.byname map there's no point in having shadow
passwords it might as well be in the public passwd.byname map.

It does this restriction by requiring the NIS client open a connection
from a reserved port less than 1024 to connect to the NIS
server. Since root is the only one that can open a reserved port root
is the only one that can authenticate against the
passwd.adjunct.byname map on Solaris (and I thought that Linux
required this as well but perhaps that is a configuration option).

I'm afraid your only option is to make the app setuid root on solaris
in order to validate passwords. Some people have setup little password
checking daemons to seperate out their apps from a small secure setuid
daemon with a secure path between them (ie. the passwd.check stuff
from the Cyrus SASL library comes to mind). Others just run as setuid
root (ie. xscreensaver).  
--

                   Network Engineer/Jack of All Trades
                      Vector Internet Services, Inc.

 
 
 

secure passwd.adjunct + pam + not set uid root binaries are not able to verify passwords - why?

Post by Thomas Glanzman » Wed, 22 May 2002 23:31:48




> >we have a secure nis map passwd.adjunct.byname and password files like this line
> >sithglan:##sithglan:31401:30003:Thomas Glanzmann, CIP Admin:/home/cip/adm/sithglan:/local/login/bin/env-csh

> >Now we have a problem ... we have some PAM applications which have to verify a
> >password and should not be set user id root ... but that does not work.

> >We compiled them with pam support. But they still need set user id root. What
> >can we do else?

> >Under Linux it works without the set user id sbit.

> Hmm I thought Linux implemented the same security action in their NIS
> client library long ago.

> The NIS server is requiring the client to have root priv's in order to
> protect the shadow password data from prying eyes. If anybody could
> access the passwd.adjunct.byname map there's no point in having shadow
> passwords it might as well be in the public passwd.byname map.

> It does this restriction by requiring the NIS client open a connection
> from a reserved port less than 1024 to connect to the NIS
> server. Since root is the only one that can open a reserved port root
> is the only one that can authenticate against the
> passwd.adjunct.byname map on Solaris (and I thought that Linux
> required this as well but perhaps that is a configuration option).

> I'm afraid your only option is to make the app setuid root on solaris
> in order to validate passwords. Some people have setup little password
> checking daemons to seperate out their apps from a small secure setuid
> daemon with a secure path between them (ie. the passwd.check stuff
> from the Cyrus SASL library comes to mind). Others just run as setuid
> root (ie. xscreensaver).

You didn't get the point.

Under Linux xlock works without sbit and with pam support from the same SUN NIS
Server. Under Solaris not, but why?

It seems that Linux pam library can open a port under 1024 to get the secure
map, but Solaris pam library can't, but why? Is there something special with
Linux pam support ... or just a configuration problem with Solaris.

--tg

 
 
 

1. xterm not able to 'exec /bin/bash' for not root-uid

Stumped....

XF86 is successfully installed, and as root I can enter the X
environment and launch xterm, or any other app. for that matter.
However,  when I enter X as a non-root user and attempt to launch an
xterm client,  a small xterm window comes up with the message 'xterm:
can't exec /bin/bash  !' , then exits after about 3 secs.  I found some
threads in comp.os.linux.setup that talk about xterm needing to be run
setuid-root, and that is how my xterm is configured.  I compared the
environmental variables between root and the other user and there are no
blaring discrepencies.  The error message leaves me guessing.  Has
anyone else encountered this problem?

Thanks in advance,

Coburn Watson

2. creating a custom linux distribution

3. Can't set root password- Password busy error -is not due to temp password file

4. New: 2.5.67: USB kills kernel on hotplug stop, wrong timer handling?

5. Why am I not prompted for a password?

6. Netscape 4.72 (128-bit) and 4.73 keeps crashing!!??

7. fixed pppd thinking set-uid-root wasn't secure enough

8. Can't load the root filesystem error message

9. Why could not startx when secure level is set to "1"

10. Announcement: Shadow passwords from NIS (SunOS passwd.adjunct)

11. I am not able to compile Emacs 19.25 under Linux anymore

12. I am not able to VPN

13. q:I am not able to install bootloader in redhat