Re: cgiwrap for Apache::ASP?
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.com1-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 ([EMAIL PROTECTED]) 51
Re: cgiwrap for Apache::ASP?
| 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?
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. -Tom
Re: cgiwrap for Apache::ASP?
| 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?
> 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. -- [EMAIL PROTECTED] | 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?
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 ([EMAIL PROTECTED])
Re: cgiwrap for Apache::ASP?
| 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