|
Grex > Coop11 > #51: Enabling CGI scripts for Grex users | |
|
| Author |
Message |
| 25 new of 59 responses total. |
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...)
|
srw
|
|
response 25 of 59:
|
Dec 17 03:37 UTC 1998 |
In response to the first paragraph of Marcus's resp:14 :
(1) if we ever did allow users to write their own CGI programs, those
programs would only be run as the user, never as "nobody".
(2) CGI programs installed by the staff are run as "nobody" today, but
this ought to be changed to another nobody-like ID, such as httpd.
Under these conditions, I believe that the only purpose of limiting
user-written CGI is to limit the kinds of services we make available
over the web. This may indeed be a valid reason, but it is not a
security reason.
|
davel
|
|
response 26 of 59:
|
Dec 17 11:29 UTC 1998 |
Way back somewhere, someone indicated that CGI programs are prone to
exploitable holes which might allow others to gain access to a user's account.
Assuming that's so: on the one hand, it's reasonable to hand users the means
to do this; but on the other hand, it might generate enough staff work to make
us want to forbid CGI.
That's not precisely a security reason, but it's not just "to limit the kinds
of services we make available over the web", either.
I'm not in a position to evaluate how pressing a concern this is, myself.
|
devnull
|
|
response 27 of 59:
|
Dec 20 05:40 UTC 1998 |
The fact that a user can create a buggy cgi that might put that user's
account at risk doesn't really bother me that much. Users can already do
other things to put their account at risk (like telling others their password),
and so I think that clearly warning people ought to be adaquate. People
who know how to write secure cgi's should lose because we're concerned about
other people's cluefulness.
Because grex allows anyone to run newuser, there's no new risk to the system
as a whole if some random cracker can gain access to some non-root account.
|
mdw
|
|
response 28 of 59:
|
Dec 20 23:47 UTC 1998 |
Yes, but grex *also* has a responsible to people to make sure that other
people can't access their mail, private files, etc. Obviously, there is
only so much we can do on this score (we can't protect against human
stupidity), but we do want to make sure that the *system* software that
implements user cgi's has no holes, and the tools exist and are well
documented so that people are not tempted to create insecure cgi
scripts.
|
sev
|
|
response 29 of 59:
|
Dec 22 18:44 UTC 1998 |
You could create a perl library for users to implement into their script with
all the counter-measures so the user wont have to worry about programming
protection agains security holes themselves
|