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

Matt Tucker tuck at whistlingfish.net
Tue Jun 26 11:55:40 CDT 2001


-- William Julien <moonbeam at catmanor.com> spake thusly:

>>> I'm not sure I quite understand your question. If user "A" and "B"
>>> run as nobody, they are effectively the same user. The server side
>>> id is the same. Web servers, by their nature, are "anonymous". So
>>> unless the server script maintains the user information via cookies
>>> or session persistant logins, the userid for all users resticted to
>>> the "nobody" capability defined by the server. The answer to your
>>> question can be "anything they want to do"; given the security (or
>>> lack thereof) of the server.
>> 
>> Right.  That's what makes it a "Bad Thing" for everyone to to have
>> their scripts run as "nobody".  Any user can do anything they want
>> to any other user.  I'd define that as bad.  It would be trivial to
>> find out where User B keeps her logs of e-mail contacts or her
>> weblogs.  User A could then plunder and spam all of User B's
>> contacts or even modify and deface her weblogs...
>> 
>> Not a good thing.
>> 
>> Yes, if it is running as the user, a bug in their scripts could cause
>> problems but not as bad as the other scenario.
>> 
>> Darren
> 
> You mis-understand. It is a "Good Thing" to have everyone run under a
> restricted userid (like nobody) than have them have free run as a
> "real" user. The nobody user generaly has less privledge than a
> normal user. This provides better security. 

It seems like there are actually two issues, and you're each offering
solutions for only one of them.

Issue #1: Having all CGI's running as nobody opens security holes by
allowing different accounts on the machine to access each other's
web-related files. One particularly bad thing about this is that it
introduces worry not only about your own and the admin's security
procedures, but also those of every other user on the system.

William claims the issues with this are solved by not allowing users to
list the home directory and using non-obvious usernames, but this is
just security through obscurity and I would be leary of trusting my
site to it. It's like believing that disabling indexes prevents
intruders from accessing unreferenced files and directories. While it's
a good practice, it shouldn't be your only line of defense.

Issue #2: Having all CGI's running as the owning user opens security
holes by preventing users from being able to protect files from their
own cgi scripts.

I think the ideal solution would address both of these issues. One
possibility might be having CGI's run as nobody, but run chrooted to
the user's html tree, but this would either result in a lot of file
duplication or severely limit the usefulness of CGI's.

Another solution might be to give each user two accounts: a standard
user account, which most files are owned by, and an individual web
account that CGI's run as. A problem with this is that a tool would
have to be provided to allow the standard user account to adjust
ownership and permissions for the web account. I also know of no site
that implements such a solution.

You might also ask, if you can't solve both issues which one would you
prefer to have to deal with? Would you rather trust your own security
procedures and programming practices or would you rather trust those of
everyone else on the system?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://mail.pm.org/archives/spug-list/attachments/20010626/d5a944f0/attachment.bin


More information about the spug-list mailing list