setuid

[Jay]

Well, mark this one up for the history books. :) I finally figured out
what the problem was. It took a little tweaking, but is running the
scripts suid now. I was installing the newest version of Apache (for
unrelated reasons), and while reading through the docs, came across a
'feature' called 'suexec'. This is an _optional_ component of Apache that
can be built at compile time. Aparently, this option was left out of the
default Slackware 3.5 setup. Anyway, the suexec feature works beautifully.
Additionally, it seems to have some great security features. I had to
remove the suid bit from all of the FreeSide CGI's for it to work.
However, the suexec part of Apache allows one to specify a directory, and
it will automatically su to the owner of any script within that directory
and run the script as that owner -- even without the suid bit set on the
script. Pretty cool indeed. :)

I have run into another problem, but I'll start another thread for that.
Thanks to everyone for the help with this. :)

~Jay

On Mon, 14 Dec 1998, Ivan Kohler wrote:

> On Mon, Dec 14, 1998 at 12:23:28AM -0700, Jay wrote:
> > 
> > Just for kicks -- here is what /var/lib/httpd/log/error-log is reporting:
> > 
> > YOU HAVEN'T DISABLED SET-ID SCRIPTS IN THE KERNEL YET!
> > FIX YOUR KERNEL, PUT A C WRAPPER AROUND THIS SCRIPT, OR USE -u AND UNDUMP!
> 
> I haven't seen this message since SunOS 4.  Maybe you should try chmod
> 4755 (not 4711) for suidperl? 
> 
> > I am tried changing cust_main.cgi to run 'suidperl' instead of 'perl -Tw',
> 
> Don't do this.
> 
> > I have tried the C wrapper (suggested in the perlsec man page), all of
> > which owned by the user 'freeside' and chmod'd 4755. I also even tried the
> 
> `wrapsuid' from the Perl distribution is a bit more robust.
> 
> > C wrapper calling the Perl script set to run 'suidperl' -- still producing
> > the same results.
> > 
> > ~Jay
> > 
> > On Mon, 14 Dec 1998, Jay wrote:
> > 
> > > 
> > > Hmmm...it would seem that my version of /usr/bin/suidperl is already 4711
> > > to root. Here's what I have:
> > > 
> > > (root at energy.kinetic.org) 00:02:11
> > > [/var/spool]: l /usr/bin/suidperl
> > > lrwxrwxrwx   1 root     root           15 Nov  6 21:12 /usr/bin/suidperl
> > > -> suidperl5.00404*
> > > 
> > > (root at energy.kinetic.org) 00:02:16
> > > [/var/spool]: l /usr/bin/suidperl5.00404
> > > -rws--x--x   1 root     bin      463936 Mar 23  1998 /usr/bin/suidperl5.00404*
> > > 
> > > Any other ideas? I am starting to get desperate here. :)
> > > 
> > > ~Jay
> > > 
> > > On Mon, 14 Dec 1998, Christian Eva wrote:
> > > 
> > > > Jay wrote:
> > > > 
> > > > > Well, some progress. I found a binary called 'suidperl' -- however, there
> > > > > is no man page for it, and I cannot find any information about how to use
> > > > > it. Any pointers?
> > > > >
> > > > 
> > > > Well I had a similar problem because in my Suse 5.3 the suidperl did not have suid
> > > > root(under the SuSE installation option secure). When perl has the setuid bit set
> > > > on its scripts it
> > > > automatically executes suidperl. After changing suidperl to "4755 owner root" the
> > > > CGI's worked fine.
> > > > 
> > > > Christian
> > > > 
> > > > 
> > > > > ~Jay
> > > > >
> > > > > On Sun, 13 Dec 1998, Ivan Kohler wrote:
> > > > >
> > > > > > > My distro did include Perl5.
> > > > > >
> > > > > > It probably includes Perl suid emulation in a separate package than the
> > > > > > normal Perl package.
> > > > > >
> > > > > > > I checked out the perlsec manpage, but that
> > > > > > > recommended that I should rename all of the CGI scripts and then create
> > > > > > > small C wrappers (with the original script name) to be setuid to call the
> > > > > > > newly named CGI. While I am sure that is a possible (but pain in the neck)
> > > > > > > solution, there has to be an easier/better way. :)
> > > > > >
> > > > > > The better way is Perl's setuid emulation, also mentioned in the perlsec
> > > > > > manpage.  If your distribution does not include this option (I'd be _very_
> > > > > > surprised if Slackware didn't), then you will need to recompile Perl.
> > > > > >
> > > > > > > I did try the perlsec
> > > > > > > method on the cust_main.cgi script, however when I executed the new C code
> > > > > > > that calls the original CGI script, it complains that setuid is still
> > > > > > > allowed in my kernel. Unfortunately, I am not enough of a coder to get
> > > > > > > into the kernel source and try to track that down.
> > > > > > >
> > > > > > > This brings me to a couple of questions: #1) how to I disable the setuid
> > > > > > > stuff in the kernel so that the perlsec method will work?
> > > > > >
> > > > > > Linux 2.0.x ignores the setuid bit on scripts, which is fine.  Perl
> > > > > > provides setuid emulation.  You don't need to change anything in your
> > > > > > kernel.
> > > > > >
> > > > > > > #2) will I need
> > > > > > > to create a C wrapper for _every_ setuid CGI script in the FreeSide
> > > > > > > package?
> > > > > >
> > > > > > That's one possible solution, yes.
> > > > > >
> > > > > > > Finally, #3) where can I get information about that perl-suid
> > > > > > > package?
> > > > > >
> > > > > > That's the name for a Debian package.  Check your distributions's
> > > > > > documentation for the equivalent.
> > > > > >
> > > > > > > > Are you sure?  *scripts*, not ELF executables?  What language?
> > > > > > > >
> > > > > > >
> > > > > > > Hmmm...good point. I just tested it with a quick bash shell script. It did
> > > > > > > not work. The script was setuid to user 'jay' but when I executed it (as
> > > > > > > user 'root') it ran as 'root'. Thus, it would seem that all of my other
> > > > > > > setuid stuff are ELF binaries.
> > > > > > >
> > > > > > > So, now that I know my kernel will not support suid scripts, and I do not
> > > > > > > have the perl-suid pagkage, and the perlsec method (making C wrappers for
> > > > > > > every suid CGI) doesn't work because of something still enabled in my
> > > > > > > kernel -- any ideas? :) Thanks for the help.
> > > > > >
> > > > > > --
> > > > > > Ivan Kohler <ivan at sisd.com> - finger for PGP key - <moc.dsis at navi> relhoK navI
> > > > > > Open-source billing and administration for ISPs - http://www.sisd.com/freeside
> > > > > > 20 4,16 * * * saytime # please don't be surprised if you find me dreaming too
> > > > > >
> > > > >
> > > > > - J a y   J a c o b s o n
> > > > > - - - - - - - - - - - - - - - - - -
> > > > > - jay at kinetic.org   www.kinetic.org
> > > > >
> > > > > Quantum Mechanics: The dreams stuff is made of.
> > > > 
> > > > 
> > > > 
> > > > --
> > > > Christian J Knoepfel Eva
> > > > Phoenix Integration
> > > > Rosebank Business Park
> > > > 333 Crumlin Road, Belfast, BT14 7EA, Northern Ireland, U.K.
> > > > Phone +44-1232-550300
> > > > 
> > > > 
> > > > 
> > > 
> > > - J a y   J a c o b s o n
> > > - - - - - - - - - - - - - - - - - -
> > > - jay at kinetic.org   www.kinetic.org
> > > 
> > > Quantum Mechanics: The dreams stuff is made of.
> > > 
> > 
> > - J a y   J a c o b s o n
> > - - - - - - - - - - - - - - - - - -
> > - jay at kinetic.org   www.kinetic.org
> > 
> > Quantum Mechanics: The dreams stuff is made of.
> > 
> 
> -- 
> Ivan Kohler <ivan at sisd.com> - finger for PGP key - <moc.dsis at navi> relhoK navI
> Open-source billing and administration for ISPs - http://www.sisd.com/freeside
> 20 4,16 * * * saytime # please don't be surprised if you find me dreaming too
> 

- J a y   J a c o b s o n
- - - - - - - - - - - - - - - - - -
- jay at kinetic.org   www.kinetic.org

Quantum Mechanics: The dreams stuff is made of.