Setuid and web sites create the biggest possible place to open security
holes on a machine, even worse than SQL injection because you can leave
the whole machine vulnerable. My suggestion (from personal experience)
is to write a small, well debugged C program that checks all its
parameters for legality, exiting if anything is wrong before it
setuid()s to the appropriate user (sometimes root, mostly someone else),
executes its system call (no, don't make it general to execute
anything), and exits. The program is stored in a directory that the
apache can't directly access and is executable only by the web user.
Examples:
Creating directories: Only allow this to be done in certain
directories (or a single directory), reject paths, reject paths with
".." in them, setuid() to the owner (or the group) of the
owner of the directory.
Executing pre-written scripts: Only allow predefined scripts.
Always use absolute paths to those scripts. Make sure the scripts have
appropriate permissions (no writeable, no suid),
don't allow general parameters to the scripts, only
allow a certain user to execute the script, setuid() to that user.
Restarting services: Limit to predefined services, check that
the service really needs restarting, possible check for failures that
happen too fast.
Changing ownership or permissions: Predefine what can be done,
code that into the program, and use a simple parameter choose what can
be done.
If this is a team project, only one member of the team should work on
the program, especially when fixing bugs.
Don't leave anything unspecified. Don't allow anything "easy" through.
Brad Davis
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
