cgiwrap for Apache::ASP?

[Philip Mak <pm...@aaanime.net>]

Hello,

I searched the egroups.com mod_perl archive for "cgiwrap" and didn't find
anything relevant to ASP.

I'm wondering if there's any documentation about how to use cgiwrap with
the ASP extension. Currently I have a modified version of cgiwrap
installed on my system such that all .cgi/.pl files are transparently
(i.e. no need to put cgiwrap in the URL) suid'ed to the script owner
before being executed.

I also have ASP installed, and I'd like to be able to transparently suid
the .asp scripts too. Do you know how I could go about doing this?

Thanks,

-Philip Mak (pmak@aaanime.net)

Re: cgiwrap for Apache::ASP?

[Ime Smits <im...@iae.nl>]

| Huh? SuEXEC only works with mod_cgi (e.g. it requires the exec() part of
| it's name to get the Su part), it is not applicable to the persistant
| mod_perl world.

Ok, I must admit I mixed up referals to the concept (setuid()) and the
imlementation (suexec).

The point I was making was that even if - hypothetically spoken - you would
get Apache to do some set(e)uid() and set(e)gid() system calls just before
script startup (like the suexec utility does), you will not get the security
you want anyway.

Ime

Re: cgiwrap for Apache::ASP?

[Tom Brown <tb...@baremetal.com>]

On Mon, 17 Apr 2000, Ime Smits wrote:

> | Also, my system has cgiexec (does suid for CGI scripts) installed. The
> | cgiexec documentation says that once cgiexec is installed, it is a
> | security risk if people can execute code as "nobody" since that user has
> | special access to the cgiexec code. Right now, anyone can execute code as
> | nobody by writing ASP code, so in essence I have a security hole in my
> | system, and I DO need cgiexec.
> 
> Like I said, doing something like suEXEC will solve your file access
> problems, but it won't prevent people from messing up things like the
> $Session and $Application objects which are accessible to all users running
> their site on this webserver. It won't even prevent a user to redefine a
> scalars, subroutines or even complete modules which are not belonging to
> their own scripts.

Huh? SuEXEC only works with mod_cgi (e.g. it requires the exec() part of
it's name to get the Su part), it is not applicable to the persistant
mod_perl world.

The rest of your discussion seems to relate to the persistance of
the mod_perl environment.

<rest of message snipped>

-Tom

Re: cgiwrap for Apache::ASP?

[Ime Smits <im...@iae.nl>]

| Also, my system has cgiexec (does suid for CGI scripts) installed. The
| cgiexec documentation says that once cgiexec is installed, it is a
| security risk if people can execute code as "nobody" since that user has
| special access to the cgiexec code. Right now, anyone can execute code as
| nobody by writing ASP code, so in essence I have a security hole in my
| system, and I DO need cgiexec.

Like I said, doing something like suEXEC will solve your file access
problems, but it won't prevent people from messing up things like the
$Session and $Application objects which are accessible to all users running
their site on this webserver. It won't even prevent a user to redefine a
scalars, subroutines or even complete modules which are not belonging to
their own scripts.

This would open up a whole new security hole, because then someone can, with
some smart work, insert handlers or redefine modules which aren't theirs and
then let the code be executed later as someone else with full access to
*all* files of victim.

One way or the other, you are not going to get the security you want.

And then again: if you just think how easily badly coded perl scripts (which
will work perfectly fine as a strict CGI) can become a major pain in the ass
(memory leakage, resource exhaustion) in a mod_perl environment, I wouldn't
trust anybody without prior verification of their coding abilities in such a
virtual hosting environment in the first place.

| So, does anyone have suggestions on how to do suid for ASP scripts?

For the occasional script where you *have* to do suexec because you're going
to have to write to disk, make them plain CGI (that is, with
#!/usr/bin/perl-thing on the first line) and use the Apache suexec.
Otherwise, rethink your concept and see what can be put in a real database.

| Wouldn't this require running one web server process for each user? I may
| be wrong, but it seems to be simpler to just suid their scripts.

Yep. But that's the only way you are going to have a real secure setup.

Ime

Re: cgiwrap for Apache::ASP?

[Joshua Chamas <jo...@chamas.com>]

Theoretically, you could run Apache::ASP scripts 
as a CGI program, which could then inherit the suexec
environment for execution, creating $Session & such 
as that suexec user.

Problem is that I have never gotten ASP to run as a full 
CGI well.  Check out the asp script in the distribution
cgi directory.  You can then run an ASP script if you
have its #cgi line as #!/usr/local/bin/perl asp.  I got it
working roughly once, everything except POST I believe,
so you might be able to patch the stuff up nicely.

Note that Apache::ASP will be dog slow run as a cgi 
with all of the perl modules it "uses" in addition to
perl compiling its own 1000s of lines of code.

-- Joshua
_________________________________________________________________
Joshua Chamas			        Chamas Enterprises Inc.
NodeWorks >> free web link monitoring	Huntington Beach, CA  USA 
http://www.nodeworks.com                1-714-625-40

Philip Mak wrote:
> 
> On Fri, 14 Apr 2000, Ime Smits wrote:
> 
> > | I also have ASP installed, and I'd like to be able to transparently suid
> > | the .asp scripts too. Do you know how I could go about doing this?
> >
> > I think this is a general bad idea. The only purpose of running scripts via
> > a suexec or setuid mechanism I can think of is to stop different users &
> > websites running an the same httpd digging and interfering in each other's
> > data and files.
> 
> This server is used by many unaffiliated people who run their own
> websites. Some people want to write their own CGI or ASP scripts that work
> with files. The simplest example is a form that can be filled out and
> stores the data in a file. If I don't suid their scripts, then they can
> mess up each others' data files. They also cannot write data files into
> their own directories.
> 
> Also, my system has cgiexec (does suid for CGI scripts) installed. The
> cgiexec documentation says that once cgiexec is installed, it is a
> security risk if people can execute code as "nobody" since that user has
> special access to the cgiexec code. Right now, anyone can execute code as
> nobody by writing ASP code, so in essence I have a security hole in my
> system, and I DO need cgiexec.
> 
> So, does anyone have suggestions on how to do suid for ASP scripts?
> 
> > If you're not trusting the people making websites and you're looking for a
> > virtual hosting solution, I think some postings earlier this week about
> 
> That's exactly the case here.
> 
> > proxying requests to a user-dedicated apache listening on localhost is the
> > best solution.
> 
> Wouldn't this require running one web server process for each user? I may
> be wrong, but it seems to be simpler to just suid their scripts.
> 
> -Philip Mak (pmak@aaanime.net)
51

Re: cgiwrap for Apache::ASP?

[Tom Brown <tb...@baremetal.com>]

> Also, my system has cgiexec (does suid for CGI scripts) installed. The
> cgiexec documentation says that once cgiexec is installed, it is a
> security risk if people can execute code as "nobody" since that user has
> special access to the cgiexec code. Right now, anyone can execute code as
> nobody by writing ASP code, so in essence I have a security hole in my
> system, and I DO need cgiexec.
> 
> So, does anyone have suggestions on how to do suid for ASP scripts?

no (because there isn't an easy, or even moderately difficult one), but
the solution to the "nobody" problem is to run your mod_perl webserver
under a "modperl" userid. 

----------------------------------------------------------------------
tbrown@BareMetal.com   | Put all your eggs in one basket and 
http://BareMetal.com/  |      WATCH THAT BASKET!
web hosting since '95  | - Mark Twain

Re: cgiwrap for Apache::ASP?

[Philip Mak <pm...@aaanime.net>]

On Fri, 14 Apr 2000, Ime Smits wrote:

> | I also have ASP installed, and I'd like to be able to transparently suid
> | the .asp scripts too. Do you know how I could go about doing this?
> 
> I think this is a general bad idea. The only purpose of running scripts via
> a suexec or setuid mechanism I can think of is to stop different users &
> websites running an the same httpd digging and interfering in each other's
> data and files.

This server is used by many unaffiliated people who run their own
websites. Some people want to write their own CGI or ASP scripts that work
with files. The simplest example is a form that can be filled out and
stores the data in a file. If I don't suid their scripts, then they can
mess up each others' data files. They also cannot write data files into
their own directories.

Also, my system has cgiexec (does suid for CGI scripts) installed. The
cgiexec documentation says that once cgiexec is installed, it is a
security risk if people can execute code as "nobody" since that user has
special access to the cgiexec code. Right now, anyone can execute code as
nobody by writing ASP code, so in essence I have a security hole in my
system, and I DO need cgiexec.

So, does anyone have suggestions on how to do suid for ASP scripts?

> If you're not trusting the people making websites and you're looking for a
> virtual hosting solution, I think some postings earlier this week about

That's exactly the case here.

> proxying requests to a user-dedicated apache listening on localhost is the
> best solution.

Wouldn't this require running one web server process for each user? I may
be wrong, but it seems to be simpler to just suid their scripts.

-Philip Mak (pmak@aaanime.net)

Re: cgiwrap for Apache::ASP?

[Ime Smits <im...@iae.nl>]

| I also have ASP installed, and I'd like to be able to transparently suid
| the .asp scripts too. Do you know how I could go about doing this?

I think this is a general bad idea. The only purpose of running scripts via
a suexec or setuid mechanism I can think of is to stop different users &
websites running an the same httpd digging and interfering in each other's
data and files.

As Apache::ASP is built on top of mod_perl which takes advantage of
*internally sharing & caching* as much as possible between httpd processes,
doing setuid scripts would not fix the problem.

I'm not into the gory details, but I guess what you have then is the same
access to the same data as before, you just have another uid. So for disk
i/o this is ok, but to shield users from messing up each others mod_perl
namespace in case they have a bad coding style, this is useless.

If you're not trusting the people making websites and you're looking for a
virtual hosting solution, I think some postings earlier this week about
proxying requests to a user-dedicated apache listening on localhost is the
best solution.

Ime