• Web server running as 'nobody', CGI scripts owned by you, 'user' in an inconsequential group. A good set of permissions: 755.
• Web server running as 'nobody', CGI scripts owned by you and other members of a 'webdocs' group. Your umask is probably set up 002 and the directories are g+s. A good set of permissions for your scripts: 775 (permitting others in the 'webdocs' group to modify them, but still nobody else).
• Web server running as 'webuser' in the 'webuser' group. CGI scripts owned by you in an inconsequential group. A good set of permissions: 755, or even better: chgrp 'webuser' and 750 (only group 'webuser' needs to read them). This is more secure than above examples, because only you and those that need to see the script can read/execute it. Of course, if somebody exploits a poorly written script elsewhere, it's possible he can still get at the contents.
• Web server running as 'webuser' in the 'webuser' group. CGI scripts owned by you and a 'webdocs' group. A good set of permissions: 775. This is how many corporate environments are set up (see umask and other information above for how the directories are set up), so that a group can maintain documents, but we don't get as much out of running the server as a real user (versus 'nobody'), since everything has to be world-readable anyways.
• Web server running as 'webuser' in the 'webuser' group. CGI scripts owned by a 'webdocs' user and the 'webuser' group. All modifications are done through a role account, ensuring homogenous ownership. A good set of permissions: 750. The 'webuser' group can read/execute, so the web server can get at it, but the world can't do squat, so it's reasonably secure outside of your circle of webuser group and the webdocs account.

Note that all of these examples never once give the web server write privileges of your script. This is pretty important, and your web documents are the same. (Don't, for example, put the user the web server runs as in, say, the 'webdocs' group.) If your web server is broken into, or your scripts have a vulnerability allowing people to execute arbitrary code or commands, they'll only be doing this as the 'webuser' user, which means they can see and execute your other scripts, but cannot change them. Though in all practicality, with enough skill, this level of access is typically just a springboard to some other local system exploit giving them root access, but the vast majority of site break-ins don't go this far. Usually they're just out to deface a web page, in which case permissions like this would stop them.

If you did want to go a bit further as another poster suggests, you could further restrict 'production' code and web pages to the user the web server runs as, and set its permissions horribly restrictive (500 or 400 for web pages). Of course, doing this would allow a potential intruder to simply execute a chmod command and get full write privileges again. Even though it may look more secure, that sense of security is false.

711 won't work because although you're making it executable for owner, other, and everyone, it won't work unless you also give "read" permissions to everyone. (At least, this is in my experience... someone please correct me if this is different under some combinations of Apache and *nix.)

755 is your best bet. This makes your code both readable and executable by all, and that is the minimum requirement for someone to use it via a webserver. "Everyone" has to be able to run it, and "everyone" has to be able to read it. You have to open the barn doors like that or no one would ever get the benefit of your wonderful widget. There's no security hazard in giving read access to an executable script, because unless you have a badly configured Apache server any accesses to an executable file will execute the code and not display your source, so you don't have to worry about Everyone just "reading" your CGI. (Of course, this doesn't apply to people who actually have legitimate accounts on the webserver. They count as "everyone" too and they'll be able to cat your source code.)

The security issues here do not lie with access to your CGI, but rather in ensuring that your CGI cannot do anything beyond what it's suppossed to do. This can be an easy thing to do (as in your example of a simple hex/dec converter, where the only thing the CGI does is spit things back to the browser) to more complex things that involve writing to files on the server or updating databases or such. The Evil that Bad People do with your CGI is limited by the access and actions that your CGI has; the more narrowly focused your task, the fewer options Bad People have to abuse your code.

Gary Blackburn
Trained Killer

CGI's must be executable by everyone

AFAIK, this is configuration dependent. Commonly, Apache is often set up to run as the user 'nobody' (group 'nogroup'), and the scripts are owned by some user, i.e. 'webmaster', or possibly by root. In this case, the scripts must be world-executable, because the server is not running as the same user or group as the owner.

However, this is not always the case. My personal webserver, for example, runs as the user 'httpd', and is a member of the groups 'httpd' and 'web'. My PHP pages (the same rules apply as for CGI scripts) are owned by user 'rlk' (me), and have group 'web'. Since the server is a member of group web, the pages need only be group-executable. One advantage of doing it this way is that some of the pages need things such as database passwords hard-coded into them, and if they were world readable (a script must be readable to be executable), then any user on my system could read the script, learn my mysql password, and trash my database.

--
Ryan Koppenhaver, Aspiring Perl Hacker
"I ask for so little. Just fear me, love me, do as I say and I will be your slave."

well, let's take a look : )

take a simple script secure.pl:

#!/usr/bin/perl -w

use strict;
use CGI qw(:standard);

my $string = 'this is the string.';

print header;

print qq!
<HTML><HEAD><TITLE>DUH</TITLE></HEAD>
<BODY>$string</BODY></HTML>
!;
[download]

Let's give it 711...oops. We get error 500 from Apache. Why? Because the file is now -rwx--x--x, which means the owner (first three bits after leading -), can read 'r', write 'w', and execute 'x' it, anyone else in the owner's group (represented by the next three bits, note that only the 'x' is there meaning the other two abilities are denied to the group) can execute it and general public can execute it. But what that means is that the account which Apache runs under - typically and rightfully nobody - cannot read the file, only execute it. But a lot of good it does to execute a Perl script you cannot read...

When we try 744, we get the Forbidden message from Apache. now the file is -rwxr--r--, which mean the owner can still do anything but the group and world can only read it. So Apache gets a chance to see the file but can not execute the code within.

finally i set it to 755(-rwxr-xr-x) and it all goes well because nobody, in fact every one on the system, can read and execute the file.

What it boils down to is that the account which runs the webserver is given no special privalege to the files containing your Perl code. So that means the account who runs the webserver (again, typically nobody) must have both read and execute permissions on the file involved. So, the amount of security you provide on the files themselves is determined by whom and how people have access. I have known people who give ownership to all production scripts to nobody and set them all to 500(-r-x------). That way the scripts in production can ONLY be run and read by the webserver and anyone who sees them through the webserver (all black hatting aside).

Most of the time, though, when it comes to CGI security, the files are not the first concern. You seem to be aware of that from your statement that this is a simple program, which seems to say "I beg you not to spout off about taint checking". I respect that. : ) I hope this is helpful.

"sometimes when you make a request for the head you don't
want the big, fat body...don't you go snickering."
                                         -- Nathan Torkington UoP2K a.k.a gnat

I have known people who give ownership to all production scripts to nobody and set them all to 500(-r-x------). That way the scripts in production can ONLY be run and read by the webserver and anyone who sees them through the webserver (all black hatting aside).

From a security standpoint this is a very bad, bad idea. The whole purpose of the 'nobody' account is that it has NO special privileges. Nothing should be owned by it, nothing should be available just to it. If you want something readable or executable to 'nobody', you should do so by making your file/script world-readable and -executable. If you have a problem with that, you should set up your users/groups/ownerships a bit differently (running the web server/whatever as a real user, for example). Any potentially insecure daemon that runs as nobody and is broken into would, in theory, be restricted to the 'nobody' user, which means they shouldn't be able to do anything to any files (though they might be able to fill up, say, /tmp). If you give them ownership of a bunch of files like your web docs/CGI scripts, even with a restrictive set of permissions, they're just one chmod shy of defacing your site and finding ways of elevating their privileges further.

Granted, with a suitably equipped intruder, even with the 'nobody' account they can find ways of getting deeper into your system with any local account, most intruders of this nature can not, and only through script-kiddie-friendly installations such as this do they get to deface web sites without working outside of the user the web server runs as.

if you're confused about what the numbers (bit masks) mean, i suggest using what i like to call a "UNIX filesystem primer" like midnight commander. if you're using terms like "secure", then 711 is "more secure" than 744 since it reduces permissions (if that's what u ask)...

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

- Zoogie

If you have a system where you have a bunch of users executing their own CGI scripts, you probably want to do this, to limit the amount of damage a user can do. Take it a step further and put resource/file system limits on users as well.

Just be advised that if you're allowing users to run their own CGI scripts, you can forget about security. Odds are, they've got some insecure stuff up there, and if your system is going to be compromised, this is definitely the way I'd try and do it. Except now instead of running as a 'nobody' user or a restricted web server user, they're running as a legitimate, real user on your system, which could make it a lot easier for them to get further.