Setuid Problem

Setuid Problem

Post by Real Na » Tue, 12 Nov 1996 04:00:00



Hello,

Im having problems getting setuid to work on a bsdi 1.1 system
I have set the owner of a file as root and the "s" bit as
follows:

-rwsrwxr-x  1 root  wheel    1815 Nov  3 22:59 file.pl

If I try to run the program by sending email to an alias
in the sendmail /etc/aliases file ie. alias: "|/path_to_file/file.pl"
the program will not run as root but as daemon with effective and real id
of "1".

Can anyone suggest a way to get this working?

Thanks,
Phil

 
 
 

Setuid Problem

Post by Phillip Krokid » Tue, 12 Nov 1996 04:00:00


Hello,

Im having problems getting setuid to work on a bsdi 1.1 system
I have set the owner of a file as root and the "s" bit as
follows:

-rwsrwxr-x  1 root  wheel    1815 Nov  3 22:59 file.pl

If I try to run the program by sending email to an alias
in the sendmail /etc/aliases file ie. alias: "|/path_to_file/file.pl"
the program will not run as root but as daemon with effective and real id
of "1".

Can anyone suggest a way to get this working?

Thanks,
Phil


 
 
 

Setuid Problem

Post by Ian Fin » Tue, 12 Nov 1996 04:00:00



> Hello,

> Im having problems getting setuid to work on a bsdi 1.1 system
> I have set the owner of a file as root and the "s" bit as
> follows:

> -rwsrwxr-x  1 root  wheel    1815 Nov  3 22:59 file.pl

> If I try to run the program by sending email to an alias
> in the sendmail /etc/aliases file ie. alias: "|/path_to_file/file.pl"
> the program will not run as root but as daemon with effective and real id
> of "1".

> Can anyone suggest a way to get this working?

> Thanks,
> Phil


If your Perl script is trying to write to a file, then in general
kernel won't let you unless you recompile your kernel to allow setuid
scripts.

I have been able to get around this (sometimes) by writing a C wrapper.
The wrapper has the uid set (no uid set on the script), and then
it forks and exec's the script.  

In the exec, I generally do an:

execlp("/usr/bin/perl", "/usr/bin/perl", "/path/to/file.pl", NULL);

before that, create a pipe to the child process, and redirect the
stdin and stdout to it...

And make sure that the $ENV{"PATH"} has paths to any outside program
it needs to run in file.pl.

But to solve (maybe create more) problems better, try downloading
the Perl Compiler Kit by Malcom Beatle.

This will allow you to creat a stand-alone executable of your Perl
script which you can set uid bits without hassle ;)

Ian Fink

 
 
 

Setuid Problem

Post by Ji » Wed, 13 Nov 1996 04:00:00



>Hello,

>Im having problems getting setuid to work on a bsdi 1.1 system
>I have set the owner of a file as root and the "s" bit as
>follows:

>-rwsrwxr-x  1 root  wheel    1815 Nov  3 22:59 file.pl

This only works for compiled files not editable scripts.

Jim.

 
 
 

Setuid Problem

Post by Sergei A. Golubch » Wed, 13 Nov 1996 04:00:00




>Hello,

>Im having problems getting setuid to work on a bsdi 1.1 system
>I have set the owner of a file as root and the "s" bit as
>follows:

>-rwsrwxr-x  1 root  wheel    1815 Nov  3 22:59 file.pl

>If I try to run the program by sending email to an alias
>in the sendmail /etc/aliases file ie. alias: "|/path_to_file/file.pl"
>the program will not run as root but as daemon with effective and real id
>of "1".

>Can anyone suggest a way to get this working?

>Thanks,
>Phil


Hello, Phil.

I faced such a problem some time ago.
There is a complete solution.

First. Script must be setUID. (You do it)
Second. You must use not perl (#!/.../perl) but suidperl
        (or sperl4.036 on my PC) -- this is the trick.
Third. read man perl about suid scripts -- there is many stupid limitations:
        "Smart" sperl won't allow you to do "insecure" things (e.g. write to
        files).
Fourth. At www.perl.com (or something like this) there is a warning,
         that due to bug in suidperl, it's better clear suid flags (and
         disabling suid scripts)
Fifth. At last, I create an pseudo-account w/o shell, and set up cron to
         run my (non suid) script on this mailbox.

I think it will be enough...

Good luck.

P.S. if you find another solution, please, mail!

--
Regards, SerG.

 
 
 

Setuid Problem

Post by Ian Fin » Wed, 13 Nov 1996 04:00:00




> >Hello,

> >Im having problems getting setuid to work on a bsdi 1.1 system
> >I have set the owner of a file as root and the "s" bit as
> >follows:

> >-rwsrwxr-x  1 root  wheel    1815 Nov  3 22:59 file.pl

> This only works for compiled files not editable scripts.

> Jim.

You would have to recompile your kernel for setuid scripts....
So it is possible to have setuid scripts, but that presents a BIG
security problem =(

Ian Fink

 
 
 

Setuid Problem

Post by J Wuns » Tue, 19 Nov 1996 04:00:00



Quote:> Second. You must use not perl (#!/.../perl) but suidperl
>         (or sperl4.036 on my PC) -- this is the trick.

Automagically running suidperl is a compile-time option.

From Perl's config.h:

/* DOSUID
 *      This symbol, if defined, indicates that the C program should
 *      check the script that it is executing for setuid/setgid bits, and
 *      attempt to emulate setuid/setgid on systems that have disabled
 *      setuid #! scripts because the kernel can't do it securely.

You need the #!/usr/bin/suidperl trick if your version of Perl is not
compiled with this option.

Quote:> Third. read man perl about suid scripts -- there is many stupid limitations:
>         "Smart" sperl won't allow you to do "insecure" things (e.g. write to
>         files).

These limitations are IMHO everything else than stupid: they basically
try to prevent the programmer from his own stupidity by checking the
``taintedness'' of a particular variable before doing something
dangerous with it.  Nobody says you can't write files in suid Perl
scripts -- but you normally cannot create files where the names have
been passed by a user on the command line or in an environmental
variables, or derived from the script's input.  (There are methods to
validate such names, and bypass the restrictions once you are certain
about the name.  The Perl man pages mentions this.)

And, Perl prevents you from accidentally spawn a shell as part of a
system() call.  (That doesn't mean you couldn't use system() at all,
but you can't use it with arguments that require a shell.)

IMHO, all these measures make it much safer to write a setuid Perl
script than writing a setuid C program without all these safety belts.

Quote:> Fourth. At www.perl.com (or something like this) there is a warning,
>          that due to bug in suidperl, it's better clear suid flags (and
>          disabling suid scripts)

This is ridiculous.  The proposed fix doesn't work btw., at least not
on FreeBSD and NetBSD.  The setuid script is simply ignored there.

The best fix is to avoid ``Posix saved IDs'' for Perl.

To the best of my knowledge, a suidperl compiled with the following
settings on a 4.4BSD system can be considered secure:

/*#undef        HAS_SETEGID             /**/
/*#undef        HAS_SETEUID             /**/
#define  HAS_SETREGID            /**/
#define  HAS_SETREUID            /**/
#define  HAS_SETRGID             /**/
#define  HAS_SETRUID             /**/

--
J"org Wunsch                                              Unix support engineer

 
 
 

Setuid Problem

Post by J Wuns » Thu, 28 Nov 1996 04:00:00



> If your Perl script is trying to write to a file, then in general
> kernel won't let you unless you recompile your kernel to allow setuid
> scripts.

suidperl is the official way out of this dilemma.  It also enables
taint checks, which is something you really wanna have for a setuid
script.  (I think plain Perl does detect its suidness, and refuses to
run this way with your C wrapper, of course, unless you also set the
real UID inside the wrapper.)

--
J"org Wunsch                                              Unix support engineer

 
 
 

1. Need help with setuid() problems on 386/ix with setuid root program.

I have a program that needs to be able to do the following under ISC 386/ix
(System V R3.2):

        setuid to one of about 3 different accounts ("Account X")
        do some work under that ID.
(*)     setuid back to the ID of the person that originally ran it.
        send some mail to Account X saying what was done.

The program needs to be able to change to one of the 3 or so different
accounts, so It's made setuid root. It doesn't actually want to do its
work under uid root, so it setuid's to whichever account it needs immediately.
[ It can't setuid to ANY account, only to one of the 3 or so ].

The problem is that when the program send the mail to X, I want it to come
addressed from the person that ran the program, not from X.

According to the manual, you can setuid() to the saved-uid from exec();
but I can't get the setuid back to the persons ID to work. (*)

        Can anyone shed some insight on my problem?

                                        thanks
                                                Greyham.
--
/*  Greyham Stoney:                            Australia: (02) 428 6476  *

 *          "BUT THAT'S JUST A BUTTON ON A STRING, BASICLY!!!"           */

2. not able to start lilo after re installing windows

3. mysterious shared library problem (setuid problem?)

4. problem with ppp not connecting

5. Linux C-news relaynews setuid problem

6. 2.4.16 and gcc 3.0.2

7. Setuid problems & OpenSSH X-forwarding

8. Which graphics card for a new Linux machine?

9. setuid problem?

10. setuid problems

11. setuid() problem ?

12. setuid problem on Solaris 2.4x86?

13. SETUID problem/question?