SPUG: setuid & CGI security (was: site clutter)

William Julien moonbeam at catmanor.com
Tue Jun 26 01:39:09 CDT 2001


>>
>>Hmmm. Can you explain why it is a "Bad Thing" to have your server
>>running as user "nobody" and group "nobody"? It would seem to me, that
>>this would provide better security for the system if you ran scripts
>>as an unprivlidged user. If your cgi scripts were run under setuid,
>>a poorly written script can gain access to files (owned by them) that
>>were not explicily permitted by the owner as world write.
>
>The problem with running CGI scripts as "nobody" is that any files 
>that your scripts can access can also be accessed by any other user 
>on the system.  If you're running your own dedicated web server, this 
>isn't a problem; but in a multi-user, virtual-server setup like 
>drizzle's this is a big problem.
>
>If a script runs as setuid, then I can make files accessible to that 
>script while hiding those files from other users.  This is a Good 
>Thing.  If a script runs as "nobody," then in order to have my script 
>read from a file (such as a password file, for example) I have to 
>make that file world-readable; and if the script needs to write to a 
>file, then I need to make that file world-writable.  These are Bad 
>Things.

An interesting perpective. For the sake of protecting a few select files
from writing by local users (remember, regular html files still need
a permission of 644 and thus are still available for global viewing), it
seems your are more comfortable exposing *all* files to world read/write
access to a larger anonymous web community. Hmmm.

It seems to me to a better idea to restrict the larger anonymous set of
users that have no local interest from read/write access to all files
than to permit write access to the few files by a smaller set of local users.

Also, knowledge of the local userid is protected since the /home directory
is resticted from browsing (surfing) by local users. The virtual
domain definition hides the owning userid of the domain. Therefore,
it is difficult for a local or remote user to know that which userid is
associated to a domain, unless provided within the context of the page
(guilty). Given just my domain name, catmanor.com, you would have no
way to know the maintanence userid. 

For the best security, your userid should not be listed on your web page
(guilty). Without this information, even a local user, will find
it difficult to know where to look. However, given access via setuid cgi,
you have now provided the capability of both local an anonymous users
to crack your web site. It is as simple as forgetting to strip a ';'
from a sendmail command line in your cgi mailer or survey.

This is a Bad thing.

>
>>
>>Halcyon is much more permissive. For example, they allow cgi scripts to
>>be located within your document root (cgi-pvt). A "Bad Thing".
>>
>
>Now I have a question: why is allowing CGI scripts in the document 
>root a "Bad Thing"?  Most providers I've used allow this, and I 
>personally find it very convenient: it allows me to put scripts where 
>they belong logically in the site hierarchy rather than off in a 
>cgi-bin directory, and lets me create prettier URLs. (One favorite 
>trick of mine is to use index.cgi files to create "extensionless" 
>URLs:  http://www.foo.com/bar/index.cgi can be accessed as simply 
>http://www.foo.com/bar/ )

If one forgets to put an "index.html" in ones cgi-bin you can get a lot
of insight to the cgi structure of the server by browsing the cgi-bin
directory. It is a very common mistake. I have used this myself to learn
more about how a website is structured.

Also, it makes the portabiliity of the scripts more difficult. I had to
edit all my html cgi pages that used the non-standard halycon 'cgi-pvt' or
'scripts' alias to the standard 'cgi-bin' syntax used by drizzle. I also
found it difficult to mirror the non standard config on my local server
which I use for development. 

By the way, I agree with you that the server side "index.cgi" is very
handy. However, most often I find I can use a client side alternative. 


   William Julien           _,'|            _.-''``-...___..--';
moonbeam at catmanor.com      /, \'.      _..-' ,      ,--...--'''
 vi is my shepherd;       < \   .`--'''      `     /| 
 i shall not font.         `-,;'              ;   ; ;  
                     __...--''     __...--_..'  .;.'  
                    (,__....----'''      (,..--''     
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
perl -e '( $ ,, $ ")=("a".."z")[0,-1]; print "sh", $ ","m\n";;";;"'


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/





More information about the spug-list mailing list