[2867] in WWW Security List Archive
Re: Security aspects of Microsoft FrontPage server extensions?
daemon@ATHENA.MIT.EDU (Albert Lunde)
Sat Aug 31 11:53:08 1996
To: www-security@ns2.rutgers.edu
Date: Sat, 31 Aug 1996 09:17:13 -0500 (CDT)
In-Reply-To: <199608310535.AAA00717@data.mr.net> from "Scott Lystig Fritchie" at Aug 31, 96 00:35:13 am
Reply-To: Albert-Lunde@nwu.edu (Albert Lunde)
From: Albert-Lunde@nwu.edu (Albert Lunde)
Errors-To: owner-www-security@ns2.rutgers.edu
I am personally amazed by the absence of concern for security in
commercial products that want to be installed as cgi scripts,
and the general failure to exploit what Unix mechanisms exist
to control access.
I was evaluating three different commercial web indexing tools.
All three recommended that they be run under the same UID
as the web server, yet in all cases I was able with a little
effort to get them to run as a separate uid and group.
In the latest case, I made the administrative cgi binaries
(which had to write to the database and config files)
setuid and setgid to that user and group. (I also
domain limited and password protected access.)
This seemed like an obvious idea to me, but the manual
didn't even hint at it. (At least one package wanted to be installed
as root but created lots of world-writable files.)
Regarding the frontpage program of restarting the server
to reread the configuration files: why not create a small
program that does nothing but send a SIGHUP to the appropriate
process (or whatever), and make it setuid to the uid
that runs the webserver?
There may not be one Unix permissions setup that works
for everyone, but vendors of software that needs to be run as a CGI
should at least provide some options and show that they've
thought about it.
