|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] Running Apache CGI scripts as root?
|
Yeah, I understand that there are a number of bad security implications here. To clarify though, I don't need to run the entire script as root, I just wanted to make sudo calls within the script for certain binaries without a password. The only way I can see to do this at the moment is to disable the 'requiretty' field in the /etc/sudoers file and add the apache user there with the relevant binaries to run. So I guess this was more of a sudo question than anything, so right now I have added the following line to sudoers:
#Defaults requiretty (<--- commented out)
apache ALL= NOPASSWD: /opt/vstk/bin/, /opt/vstk/programs (folders where my binaries are located)
seems to be working but feel free to correct my syntax or point out if this is a very bad work-around..
-Mike
On Wed, Jan 13, 2010 at 1:00 PM, Jason Stelzer <jason.stelzer@gmail.com> wrote:
Running CGI scripts as root is not a good idea. In some cases it isn't
even possible. Someone correct me if this is changed, but last I
checked linux still hadn't implemented secure file descriptors. This
means that there's an inherent race condition when starting an
interpreted (not compiled starts with #!) script.
Perl, for example will not run (command line or otherwise) suid root scripts.
The secure programming howto has more info. Start here:
5.3. File Descriptors
A program is passed a set of ``open file descriptors'', that is,
pre-opened files. A setuid/setgid program must deal with the fact that
the user gets to select what files are open and to what (within their
permission limits). A setuid/setgid program must not assume that
opening a new file will always open into a fixed file descriptor id,
or that the open will succeed at all. It must also not assume that
standard input (stdin), standard output (stdout), and standard error
(stderr) refer to a terminal or are even open.
The rationale behind this is easy; since an attacker can open or close
a file descriptor before starting the program, the attacker could
create an unexpected situation. If the attacker closes the standard
output, when the program opens the next file it will be opened as
though it were standard output, and then it will send all standard
output to that file as well. Some C libraries will automatically open
stdin, stdout, and stderr if they aren't already open (to /dev/null),
but this isn't true on all Unix-like systems. Also, these libraries
can't be completely depended on; for example, on some systems it's
possible to create a race condition that causes this automatic opening
to fail (and still run the program).
Sorry if this was sent twice, I think I accidentally hit discard
instead of send on the original. So this is draft 2.
--
J.
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|