install questions

[Hal E. Fulton]

I have been thinking about installation
issues lately.

There are two areas where I'd like people's
opinions.

1. Automatic installation of dependencies.
In the absence of a good mechanism for
handling dependencies (in install.rb or
raa-install or elsewhere) -- we could always
handle it explicitly. Supposing an app X
needed libraries Y and Z -- we could write
pre_setup.rb so that it in effect did this:
- check for Y and Z
- prompt user: perform auto-install?
- try to install over net (via raa-install
or whatever)
What do you think?

2. A separate issue: I've been trying to think
what might be involved in writing an install
for a CGI (something I've never done). Some
issues are:
- How do we know what server is being used?
- How do we find the CGI directory?
- What about naming issues, e.g., Apache sometimes
wants a .cgi extension?
- File/directory ownership and permissions: How to
make everything accessible as needed without
introducing security holes?

Hal

 

[Ben Giddings]

1. Automatic installation of dependencies.
In the absence of a good mechanism for
handling dependencies (in install.rb or
raa-install or elsewhere) -- we could always
handle it explicitly. Supposing an app X
needed libraries Y and Z -- we could write
pre_setup.rb so that it in effect did this:
- check for Y and Z
- prompt user: perform auto-install?
- try to install over net (via raa-install
or whatever)
What do you think?

I'm not completely sure I understand the question. Are you saying that if
install.rb / raa-install doesn't automatically install the needed
dependencies, that something else would, and if so, what?

From a user-interface point of view, I like the way it works for Perl's CPAN,
so that model might be a good place to start. I think there are some tweaks
to the way that CPAN works that would be useful, but overall it makes
installing big, complex packages with cascading dependencies pretty easy.
Some of the key CPAN features include:
* a number of different mirrors so you can choose one close to you
* remembering settings so that next time it behaves the way you like
* searching mechanisms

2. A separate issue: I've been trying to think
what might be involved in writing an install
for a CGI (something I've never done). Some
issues are:
- How do we know what server is being used?
- How do we find the CGI directory?
- What about naming issues, e.g., Apache sometimes
wants a .cgi extension?
- File/directory ownership and permissions: How to
make everything accessible as needed without
introducing security holes?

Knowing what server is being used:
* Do a 'ps' to find out what services are running and try to match against
common web servers
* Search for typical default install directories / config files
* Ask the user

Finding the CGI directory:
* If the server is Apache, finding this from the config file is relatively
easy, and finding the config file shouldn't be too hard either

ben% grep ScriptAlias /etc/httpd/conf/httpd.conf |grep -v "^#"
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

As for other servers, I don't know.

For naming issues, if I remember correctly, Apache only requires a .cgi
extension if the script isn't in a CGI directory, and that's because it uses
that extension as a MIME type that tells it to execute the file rather than
sending its contents. I don't think a CGI installer should really try to
handle this case.

As for permissions, if the file is installed as executable in the CGI
directory, it should be up to the user and the CGI writer to ensure that
things are secure. I'm not sure I understand the issue here.

Ben

 

[Hal E. Fulton]

----- Original Message -----
From: "Ben Giddings" <[email protected]>
To: "ruby-talk ML" <[email protected]>
Sent: Monday, July 28, 2003 10:02 AM
Subject: Re: install questions

I'm not completely sure I understand the question. Are you saying that if
install.rb / raa-install doesn't automatically install the needed
dependencies, that something else would, and if so, what?

What I mean is: AFAIK there is no existing mechanism anywhere
for automatically installing dependencies. I'm contemplating
writing custom code to check whether dependent packages are
installed, and if not, invoke raa-install (or something else)
explicitly (remembering that raa-install itself may not be
there).

Knowing what server is being used:
* Do a 'ps' to find out what services are running and try to match against
common web servers
* Search for typical default install directories / config files
* Ask the user

Yes... perhaps one might handle Apache as the most common case,
and prompt the user otherwise. (I, for one, don't want to get into
the nightmare of how to detect a dozen different server installations.)

As for permissions, if the file is installed as executable in the CGI
directory, it should be up to the user and the CGI writer to ensure that
things are secure. I'm not sure I understand the issue here.

Well, part of this is just my sketchy knowledge of web development
in general.

When I install a CGI by hand, I typically stumble into a number of
minor problems and fix them one at a time. For example, when a CGI
is writing into a flat file, I find that the file is not writable
because of its owner and/or permissions. But I suppose if the user
is "nobody" and I just make it rwx for nobody, then the dir can
live under cgi-bin and it still won't be insecure, correct?

I'm just recalling advice of the form "Don't ever do XYZ" where I
don't recall what XYZ was, but it was not intuitively obvious how
that made anything insecure. So I'm always paranoid about putting
flat files and such under cgi-bin, though that seems to me the
natural place to put them.

Hal

 

[Ben Giddings]

What I mean is: AFAIK there is no existing mechanism anywhere
for automatically installing dependencies. I'm contemplating
writing custom code to check whether dependent packages are
installed, and if not, invoke raa-install (or something else)
explicitly (remembering that raa-install itself may not be
there).

That sounds like it would be very useful. I wish you luck with it.

Yes... perhaps one might handle Apache as the most common case,
and prompt the user otherwise. (I, for one, don't want to get into
the nightmare of how to detect a dozen different server installations.)

No, especially not at first. If you write things in such a way that someone
else can take your code and modify it for their favourite web server then
that's great.

Well, part of this is just my sketchy knowledge of web development
in general.

When I install a CGI by hand, I typically stumble into a number of
minor problems and fix them one at a time. For example, when a CGI
is writing into a flat file, I find that the file is not writable
because of its owner and/or permissions. But I suppose if the user
is "nobody" and I just make it rwx for nobody, then the dir can
live under cgi-bin and it still won't be insecure, correct?

I'm just recalling advice of the form "Don't ever do XYZ" where I
don't recall what XYZ was, but it was not intuitively obvious how
that made anything insecure. So I'm always paranoid about putting
flat files and such under cgi-bin, though that seems to me the
natural place to put them.

Generally a CGI that requires read/write access to the filesystem has some
security concerns. Most of the time the script will run as nobody on a
UNIX-like box, but 'nobody' has to have read access to /etc/passwd and other
files. Write access is even worse because that opens up the door to all
kinds of other nasties.

Any CGI which requires write access to the filesystem should be content with
writing to a file in /tmp, and should be ok with that file disappearing at
some point. As to writing to other directories, a program that's executable
via the web should not have the ability to write to another web-accessible
location unless absolutely necessary. Doing so makes whatever it writes
accessible by anybody else in the world. Writing to the CGI directory is
especially bad because the web server assumes that things in that directory
are exectables and so what's written could be a nasty script.

This rule about not writing to anything but /tmp is sometimes broken by things
which allow file uploads to a media/images directory for example, but
normally there are all kinds of precautions taken in that case.

My opinion is that if you've had to manually tweak CGIs to get them to work
it's because their author wasn't careful in following good security
practices, and any installer you write shouldn't try to work around that.

Ben

 

[Hal E. Fulton]

----- Original Message -----
From: "Ben Giddings" <[email protected]>
To: "ruby-talk ML" <[email protected]>
Sent: Monday, July 28, 2003 10:59 AM
Subject: Re: install questions

Don't want to wander too far OT... but I'm coding
in Ruby after all...

Generally a CGI that requires read/write access to the filesystem has some
security concerns. Most of the time the script will run as nobody on a
UNIX-like box, but 'nobody' has to have read access to /etc/passwd and

other > files. Write access is even worse because that opens up the door to
all

kinds of other nasties.

Any CGI which requires write access to the filesystem should be content

with > writing to a file in /tmp, and should be ok with that file
disappearing at

some point. As to writing to other directories, a program that's

executable > via the web should not have the ability to write to another
web-accessible

location unless absolutely necessary. Doing so makes whatever it writes
accessible by anybody else in the world. Writing to the CGI directory is
especially bad because the web server assumes that things in that directory
are exectables and so what's written could be a nasty script.

This rule about not writing to anything but /tmp is sometimes broken by
things
which allow file uploads to a media/images directory for example, but
normally there are all kinds of precautions taken in that case.

OK, I know there are some very sneaky tricks out there... most
of them I would never have thought of on my own.

But if my CGI chooses its own filenames and never does an eval, then
how can it be a security risk even if it happens to write into
(a directory under) cgi-bin? I assume the risk comes from other CGIs
in that case?

But regardless of where the data is stored: What about CGIs whose
inherent function is recording data from the user? E.g. a guestbook?
It has to write that stuff somewhere. Surely a database is overkill
in many circumstances.

Hal

 

[Ben Giddings]

But regardless of where the data is stored: What about CGIs whose
inherent function is recording data from the user? E.g. a guestbook?
It has to write that stuff somewhere. Surely a database is overkill
in many circumstances.

In that case, maybe. If you hard-code the filename you're writing to, don't
do any evals, and do some checks on what you're writing to the file, that
should be ok. Even then, however, you should be careful someone can't write
arbitrary javascript code into the guestbook. It wouldn't affect the web
server, but it would affect anybody reading the guestbook entries.

And, as to writing to things under cgi-bin, the danger there is that the web
server assumes things there are files meant to be executed and not files
whose contents are meant to be sent out over the web. 99% of the times, this
will just mean an error if someone tries to access /cgi-bin/guestbook.txt.
On the other hand, if the file is created accidentally as executable, and
happens to start off empty, someone could write something like
"#!/bin/sh\ncat /etc/passwd" into the guestbook.

The other issue is bugs in the language. Who knows if there's some
undiscovered bug in the Ruby code or in one of the libraries your program
requires. Since a CGI is basically a program on your server that anybody in
the world is allowed to run, it's best to be overly cautious about what might
happen.

That's why (getting back to the original point) I think it's better if you
install CGIs simply by copying them to the right directory and maybe making
them executable. Anything more than that I think is unnecessary.

Ben

 

[Carl Youngblood]

1. Automatic installation of dependencies.

In the absence of a good mechanism for
handling dependencies (in install.rb or
raa-install or elsewhere) -- we could always
handle it explicitly. Supposing an app X
needed libraries Y and Z -- we could write
pre_setup.rb so that it in effect did this:
- check for Y and Z
- prompt user: perform auto-install?
- try to install over net (via raa-install
or whatever)
What do you think?

This is a much-needed feature! I'm convinced that an auto-installer could
even be written that worked well on Windows, which would make life much
easier for those of us who want to install something that doesn't come with
the one-click installer. Perhaps a base install could even include some
compiling tools that would be sufficient to download and compile code if
necessary.