(jptxs) Re: Secure Permissions?

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

Comment on (jptxs) Re: Secure Permissions? Select or Download Code

Replies are listed 'Best First'.
RE: (jptxs) Re: Secure Permissions? by Fastolfe (Vicar) on Nov 06, 2000 at 19:04 UTC
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.	[reply]

Replies are listed 'Best First'.

RE: (jptxs) Re: Secure Permissions?
by Fastolfe (Vicar) on Nov 06, 2000 at 19:04 UTC

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.

[reply]