SetUID

[maylcc]

I'm having problem running my copied script to my server. Can anybody
who is
patient enough to help me with my problem?

I have a chpass.pl which is being executed by a change password web
utility page. This script tries to update a password on my linux
server /etc/shadow with a file permision rw------.

my chpass.pl was set to -rwsr-sr-x , with this file permission, I'm
getting an
error: Can't do setuid, When I chmod 777 the /etc/shadow then
everything
works but I'm sure its not safe to do that.

I cannot figure out how could I make this work with the original file
permission
of the files shadow and chpass.pl. Any help would be very much
appreciated.
Thanks

 

[Jens Thoms Toerring]

I'm having problem running my copied script to my server. Can anybody who is
patient enough to help me with my problem?

I have a chpass.pl which is being executed by a change password web
utility page. This script tries to update a password on my linux
server /etc/shadow with a file permision rw------.

Mmmm, sounds like something with a lot of potential security
risks. Why not let the user change his/her password when
logged in the normal way? Not everything is suitable for
being done via a web page...

my chpass.pl was set to -rwsr-sr-x , with this file permission, I'm
getting an error: Can't do setuid,

Yes, that's a feature, not a bug. Setuid'ed sripts can be very
dangerous for a number of reasons and thus Perl doesn't run
them blindly. But you can get the script to run when you switch
on taint mode for the script with the -T command line option
(e.g. by having it in the first line of your script):

#!/usr/bin/perl -T

Of course, this will require that your script is written in a
way that allows it to run in taint mode, e.g. all external
input must be checked, the environment laundered etc. See

perldoc perlsec

for a longer description. But then Perl CGI scripts etc. should
be run in taint mode anyway to help you avoid the most stupid
security mistakes;-)

When I chmod 777 the /etc/shadow then everything
works but I'm sure its not safe to do that.

It's definitely not safe! Never do that, /etc/shadow isn't meant
to be seen by anything but programs that run with root permis-
sions!
Regards, Jens

 

[maylcc]

Why are you trying to run both setuid and setgid?


Please don't take this the wrong way, but I *really* think you shouldn't
be trying to write this. You clearly don't know enough about Unix
security to have any chance of getting it right. For a start, you should
*never* be trying to run a CGI script as root.

The error you are getting is because you are on a system which doesn't
have secure setid scripts (or where perl doesn't know you have them),
and you don't have suidperl installed. This is the case for an ordinary
perl install on BSD, for example. You should turn off the setid bits on
the script, as they are not going to do anything useful.

If you insist on writing this, you need to find some way to change the
password without writing to /etc/shadow directly. Running passwd(1)
under sudo might be one way, assuming you can grant yourself the
appropriate sudo rights.

Ben

thanks for your reply. i am trying to implement a test password script
which accepts user id and password and using these parameters to auth
against the server (linux) /etc/passwd and shadow. any suggestion?

 

[maylcc]

Mmmm, sounds like something with a lot of potential security
risks. Why not let the user change his/her password when
logged in the normal way? Not everything is suitable for
being done via a web page...


Yes, that's a feature, not a bug. Setuid'ed sripts can be very
dangerous for a number of reasons and thus Perl doesn't run
them blindly. But you can get the script to run when you switch
on taint mode for the script with the -T command line option
(e.g. by having it in the first line of your script):

#!/usr/bin/perl -T

Of course, this will require that your script is written in a
way that allows it to run in taint mode, e.g. all external
input must be checked, the environment laundered etc. See

perldoc perlsec

for a longer description. But then Perl CGI scripts etc. should
be run in taint mode anyway to help you avoid the most stupid
security mistakes;-)


It's definitely not safe! Never do that, /etc/shadow isn't meant
to be seen by anything but programs that run with root permis-
sions!
                              Regards, Jens

thanks for your reply. i am trying to implement a test password script
which accepts user id and password and using these parameters to auth
against the server (linux) /etc/passwd and shadow. any suggestion?

 

[Jens Thoms Toerring]

Quoth (e-mail address removed) (Jens Thoms Toerring):

Sorry for spewing non-sense! I thought I remembered something
like that, did a fast test and things seemed to work for some
reason... I guess I better don't post while still having a bit
of a temperature;-)
Regards, Jens

 

[Peter J. Holzer]

thanks for your reply. i am trying to implement a test password script
which accepts user id and password and using these parameters to auth
against the server (linux) /etc/passwd and shadow. any suggestion?

Take a look at saslauthd. It is intended for exactly this situation
where a non-privileged process needs to check whether a supplied
password is correct. There is even a perl module for it:
http://search.cpan.org/dist/Authen-SASL-Authd/

hp

 

[J. Gleixner]

maylcc wrote:
[...]

thanks for your reply. i am trying to implement a test password script
which accepts user id and password and using these parameters to auth
against the server (linux) /etc/passwd and shadow. any suggestion?

First you say you want to update a password on a Linux server, now
you're saying you want to auth[enticate] against the server?

If you want to verify authentication, forget about /etc/passwd
and simply authenticate using telnet/ssh/whatever, provided
they have shell access.

You could also build an htpasswd file, based on /etc/shadow,
and use HTTP authentication.

If you're trying to build a Web interface to set shell
passwords, without some form of pre-authentication, you're asking
for trouble. The first thing JoeHacker will do is put in
'root', or your username, and some password, then your
server is toast.