|
Grex > Coop11 > #51: Enabling CGI scripts for Grex users | |
|
| Author |
Message |
janc
|
|
Enabling CGI scripts for Grex users
| 
Dec 3 22:33 UTC 1998 |
There has recently been some discussion among the staff of allowing
users to put CGI scripts on Grex.
CGI programs are programs that run when you submit a form on a web page.
There are several running on Grex - Backtalk, the webnewuser program,
and the web vote program are all CGIs. Currently we do not allow users
to install CGI programs on their own web pages. We could do this.
Do we want to?
First, we should be able to set this up on Grex so that it isn't a big
security risk for the system as a whole (though a badly written CGI
might still compromise the account of the user who puts it up). Apache
has an suEXEC feature that appears to be well designed. Information
about this is at http://www.apache.org/docs/suexec.html. This runs the
CGI program as the user on whose account it is installed on.
What would people do if they could install CGI scripts on their Grex web
pages? Well, the possibilities are endless. Some examples of things
people could do:
- Install any of thousands of scripts off the net, including things
like counters and guestbooks.
- Create pages that display things like current "finger" output, or
"pwho" output through the web.
- Run surveys and questionaires pages and collect data.
- Run cute things like Valerie's interactive story. (See
http://www.valeriemates.com/cgi-bin/story.cgi - it's fun.)
- Theoretically, you could put up your own Backtalk conferencing
system. This would be separate from the Grex conferencing system,
with (perhaps) separate logins, items and conferences. I think
people would hit their disk space limits pretty fast if they tried
to do this, but some of Backtalk's competitors, like COW, could
probably be run in a normal user's disk space.
- You probably couldn't make a good interface to Grex's party program
(hmmm...maybe you could do something that kind of works), but you
could certainly install one of the freeware chatroom programs on
your account.
- I could install something on my web page, that would let me read
my E-mail from my web page (presumably I'd put password protection
around this so I was the only one who could do it). I could also
send E-mail through such an interface (the mail would appear to
come from my account on Grex).
- You could probably install various kinds of web-bouncer things,
where you'd hit a page on Grex that would redirect your query to
hit a page on another site, making it look as if the query came
from Grex. I can't imagine this would be of much use to anyone,
but I suspect some folks would try it.
There are endless other possibilities - more than I'm likely to think of
off the top of my head. Obviously, for some people (like me) being able
to do this would be really attractive. There aren't many places that
let people run CGI's without charging a lot. (I don't have any such
place.) However, setting this stuff up isn't all that easy, so it's
mainly a feature of use to geeks.
It's worth noting that one of the easiest things to accomplish with a
CGI program would be to seriously compromise the security of your own
Grex account. Writing secure CGI programs is difficult anytime, and
harder on Grex. Many widely distributed CGI programs which are
reasonably secure on other systems will prove unsafe on Grex (mainly
because many programmers assume that only trusted people can actually
log onto the server - definately not true on Grex). It's actually quite
likely that if you cobble together a cute little two line CGI program
that lets people run Grex's "finger" command from your web page, then I
can use it to change your password and take over your account.
So if we offered this feature, we'd certainly attract a lot of new users
once the word got out. I don't know if those people would be drawn into
our community or would donate any money, but they'd like us. Learning
to write CGI's is very educational for people, and I think we'd see some
very cool things appearing on some of our user's web pages. But there
would probably also be some things happening that we don't approve of
that much.
|
| 59 responses total. |
steve
|
|
response 1 of 59:
|
Dec 3 22:53 UTC 1998 |
I'm twitching as I read this.
One the one hand, allowing users to do this fits in perfectly with our
goals of letting people do this. We allow access to compilers, and not
allowing CGI scripts here is kind of against that principal.
The other hand is paranoid and really worries about what could happen
here. Back when Apache first came out the code was still too untested
for me to be happy with allowing users to do anything "interesting" on
Grex, for fear of security problems. Forgive me, but when I think of
anything new to add to Grex I wonder what vandals will try and do with
it.
However, I read some things at the apache site where a system of
letting users run things as themselves (ie, not as root!) and it does
sound secure, and better yet I couldn't find anything related to known
problems with it on the vandal sites I frequent.
There are two other things that worry me some. First, since there are
a myriad of things that can be done with it, I'm hoping that a lot of
staff time isn't going to be spent on "cleaning up" after problems.
Second, I wonder what kind of load we're going to place on the system,
and how that will affect Grex. Right now, Grex is at a pretty good
place in terms of processor power and ram against the usage it sees.
I'd like to see Grex get another 64M to 128M, which would let us do more
here.
If we do this, I'd very much want it to be on a test basis to see
how things go and make it clear that it might go away if there are too
many problems with it.
I really do want to see CGI scripting here on Grex, but I'm still
twitching over the possible mis-uses of it. Still, the less paranoid
part of me thinks we should do it.
|
albaugh
|
|
response 2 of 59:
|
Dec 4 00:33 UTC 1998 |
I *am* curious about how running /usr/bin/finger or whatever from your perl
script would allow a hacker to change your password. But from a mischief
point of view, if staff is convinced that a CGI could do no more harm than
what someone could already do from a UNIX shell (telnetting in), then it might
be OK to try allowing CGI for the masses.
|
krj
|
|
response 3 of 59:
|
Dec 4 05:48 UTC 1998 |
Is this something which could be done on a separate machine?
Would running the CGI web pages on a separate machine limit the
security exposure?
|
sironi
|
|
response 4 of 59:
|
Dec 4 12:14 UTC 1998 |
This response has been erased.
|
sironi
|
|
response 5 of 59:
|
Dec 4 12:15 UTC 1998 |
Sure it will be very interesting to have :-)
I've quit stopped to telnet in Grex since my linux installation.
But this is a sort of nice thing i can't afford at home!
luca_
ps i mean...stopped to telnet but not to backtalk for conferencing :-)
|
mta
|
|
response 6 of 59:
|
Dec 4 16:17 UTC 1998 |
Oohhh, that is so tempting...and I would be fascinated to see what our
creative community makes of CGI. ;)
I'd be interetsed in knowing the answer to Ken's question resp:3 but my
first reaction is an "Oh, yeah! Lets test this concept!
|
steve
|
|
response 7 of 59:
|
Dec 4 16:28 UTC 1998 |
No, we'd have to run them here, unless all web access/accounts
were on that other system. Ultimately, we could create another
machine I suppose, for web stuff, but there would still be security
problems, in that anyone could have access to that machine, so the
potential problems with CGI things would still be there.
|
valerie
|
|
response 8 of 59:
|
Dec 6 18:19 UTC 1998 |
This response has been erased.
|
janc
|
|
response 9 of 59:
|
Dec 6 19:17 UTC 1998 |
Re #2: Your "finger" web page probably has a dialog box where a person
can type in the name of a user and then hit submit to finger that user.
So your CGI program probably runs "finger <whatever-the-user-typed>" and
displays the output. But suppose the user types "; chmod 777 $HOME", so
your program runs the command "finger ; chmod 777 $HOME". He's now
permitted your home directory writable to everyone. He can log in to
your account and delete all your files. Since your finger script lets
anyone in the world run arbitrary commands on your Grex account, it's
not too difficult to take over the account. This is only one of the
simpler examples of the kind of possibilities a programmer has to think
about. There are lots more, which are much more subtle. Many widely
distributed CGI programs aren't written well, or are written with the
assumption that an attacker will have access only through the web page
and will not also have a login account on your server. If we permitted
CGI's I'd probably try to write up a page on CGI security, but it's hard
to cover all bases and most people wouldn't read it.
I've seen some setups that set strict resource limits on CGI - so that
an individual CGI couldn't use up more than X seconds of CPU, Y bytes of
memory, and so forth. That would keep any individual CGI invocation
from causing too much trouble. It's certainly something we must do -
I've seen lots of lousy CGI programs that go into infinite loops and
keep running until someone kills them. It doesn't solve the problem of
small CGI programs like web counters where no run is very big, but there
are so many hits that it adds up to a lot of load. Is there a way we
could limit the maximum number of CGI hits per day per user?
You could have CGIs running on a separate server. I'd want to get
kerberos in place first, and while this would avoid problems with CPU
load from CGI's swamping Grex, they could still swamp the net
connection.
If someone finds a nice web mail read/send script, it will probably be
passed among many of the people who use Grex as a mail site, so they can
read their mail without having to telnet in. Probably the script will
be inefficient and insecure, and Grex staff will be tempted to write a
sound one just to stop people from running the awful ones. Which might
be a step down the slippery slope of becoming a Hotmail-style web email
service.
People who set up a CGI on an account and don't log in regularly, would
see their account expire and disappear, CGI programs and all, even if
the CGI's are regularly used.
It's hard to evaluate this. There are lots of potential problems, and
lots of cool possibilities.
|
steve
|
|
response 10 of 59:
|
Dec 6 19:21 UTC 1998 |
I'm willing to try it, as long as we can pull the plug if we
need to.
|
srw
|
|
response 11 of 59:
|
Dec 6 20:56 UTC 1998 |
We webmasters do get a very large number of requests for this from
people who write mail to webmaster. Our response is always the same...
"sorry, no"
This is deeply cool. That in turn would cause lots of people to come to
Grex simply to get access to it. The result could be more demand for
Grex's resources.
The same could be said about free email, and web-based conferencing,
too, so it all boils down to whether this service fits in to what we
want to supply. I don't know.
If all people did was to use this, never logging in or using backtalk,
then they would lose their accounts due to inactivity just as people do
today, who only use Grex to host their web site or forward their mail.
We don't run a POP server for a reason. If users can get an
equivalent service by this route, a choice has to be made: either don't
allow them to use CGI for mail, or give up on forcing people to telnet
in to get their mail.
We might wish to be able to pull the plug on selected uses of it, or if
that fails, as STeve suggests, pull the plug on the whole idea.
However, short of manually policing the CGI, it beats me how we might
disallow some kinds of CGI use while permitting others.
I find it worrisome to contemplate a free web counter or even a free
form-to-mail gateway, running here without limitations on its use.
|
remmers
|
|
response 12 of 59:
|
Dec 6 23:10 UTC 1998 |
Steve Weiss raises some interesting points.
If a user's CGI's run as the user, wouldn't a simple CGI (submit
and run a shell command via a form) and basic authentication give
them their own web login shell? Interactive programs like 'party'
and 'write' would be problematic, but they could certainly read,
compose, and send mail through a simple form interface.
That would indeed be exceptionally cool if Grex has the resources
to support it. But does it? And if we have the resources to
support some kinds of user CGI's but not others, I too am baffled
as to how we'd enforce restrictions.
What are the reasons for not having user CGI's run as 'nobody',
the same way system CGI's do? (I assume there are good ones; I
just don't know what they are.) It would give more control over
the resources the CGI could access.
(The mail example may be a red herring. I leave it as an exercise
for the technically-inclined reader to explain how reading and
sending mail can be done via incoming ftp. All users can access
incoming ftp. CGI's wouldn't give users new capabilities in this
area.)
|
remmers
|
|
response 13 of 59:
|
Dec 6 23:17 UTC 1998 |
(Make that reading mail by ftp. Sending would be possible too
if they can send mail to grex from offsite. But then they could
probably send it directly to where they want it to go. Does
anybody know what I'm talking about? ;-)
|
mdw
|
|
response 14 of 59:
|
Dec 6 23:47 UTC 1998 |
"nobody" is not really "nobody", it's a particular "somebody". Like any
other "somebody", it has the rights to kill other processes it owns, to
create and delete files (if it has permissions), the system per-user
process limit applies to it, and so on & so forth. If we introduce the
notion that users can run their own "nobody" scripts, then users can
start to "play games" here. They could kill off other instances of
"nobody". They could stuff files into /tmp/. Some of the system cgi's
have various kludges in them to authenticate users (such as backtalk).
These mechanisms become accessible to any other program running as
"nobody".
I'm not sure how we'd go about enforcing limits. But I think I'd like
to see us hold off until we can run them on a separate machine, which
means I'd like to see us deploy (1) kerberos, and (2) some form of
secure distributed filesystem, so users can have one home directory
accessible from more than one machine.
|
mta
|
|
response 15 of 59:
|
Dec 7 00:17 UTC 1998 |
As cool as CGI sounds, and as in line with Grexes purpose (to provide
resources for people to learn from) as it would be to have it here, it really
sounds like it isn't practical to open it up here. At least not yet.
This may be a stupid idea -- and certainly it would mean work for *someone*
-- but would it theoretically be possible for users to write CGI scripts and
submit them to be kept in a Grex stable for use by everyone? a) would that
reduce the reosurces providing CGI would cost or increase them? b) would that
help with potential security problems, assuming that someone who knows what
they're looking at were assigned to review assigned scripts and either approve
and implement them or or disapprove them?
|
remmers
|
|
response 16 of 59:
|
Dec 7 00:24 UTC 1998 |
I knew that "nobody" is just a particular "somebody", but hadn't
thought through all the implications of that. One could at least
preventing game-playing with the system CGI's by having user
CGI's run as another anonymous somebody, say "nobody2", but
then people could still work mischief on other users, which is
probably nearly as bad.
|
remmers
|
|
response 17 of 59:
|
Dec 7 00:28 UTC 1998 |
Misti slipped in with #15. That would control some potential problems,
but I'm afraid the administrative overhead would be excessive. I
know what it's like to read through gobs of source code written by
other people. I wouldn't relish being cgiadm.
|
albaugh
|
|
response 18 of 59:
|
Dec 7 02:15 UTC 1998 |
Is it possible for the web server to "deny" cgi submits from sites other than
its own? If so, that would prevent people from writing grex-hosted hit
counters and offering them to "the world".
|
hhsrat
|
|
response 19 of 59:
|
Dec 7 02:21 UTC 1998 |
Couldn't you offer CGI the same way you offer outbound telnet? Paying members
have access to it, and non-paying persons don't. That would drastically reduce
the number of people who have access to it, thus making it much easier to
police.
|
mta
|
|
response 20 of 59:
|
Dec 7 03:52 UTC 1998 |
That might be tricky if someone wrote a CGI script, sent in membership for
three months and then let their membership lapse. Someone or something would
have to track down all CGI scripts and verify that they were accessible only
by members.
|
scg
|
|
response 21 of 59:
|
Dec 7 04:35 UTC 1998 |
CGI programs run by the server getting a request from a web browser, so the
CGI program doesn't necessarily know what page caused it to be run.
|
remmers
|
|
response 22 of 59:
|
Dec 7 10:36 UTC 1998 |
The suggestion in resp:19 is technically feasible to implement,
but I doubt we'd want to do it, as it moves membership away from
"donation" and toward "payment for services".
|
scott
|
|
response 23 of 59:
|
Dec 7 11:47 UTC 1998 |
I think it would be cool to offer all sorts of services, but I don't
think we can afford to do that.
In the future we are very likely going to have to decide whether to cut
certain services, when popularity exceeds our capacity. I'd rather we
didn't add to what we offer, just to postpone that sort of decision. We
give out a lot already.
|
devnull
|
|
response 24 of 59:
|
Dec 10 11:21 UTC 1998 |
It seems to me that having some limit on cgi hits which would be enforced
by the honor system, much the way we handle disk space, would probably work...
(Whether grex has the capacity to deal with cgi at all is a completely
different question, of course...)
|