Solved

How to run a CGI script as root with password prompt

Posted on 2003-11-07
9
1,499 Views
Last Modified: 2012-06-27
I am looking for a secure way to have a Perl script to run as root under Apache.  The user would be prompted for a password and this password would be verified.  Naturally I would use SSL on the script so that the password does not get passed in the clear.  This is for a commercial product so it cannot be too dependant on system specific configurations.

Things that I have looked into are:

- SUExec (does not support root)

- Using system(SU) - Generally SU is not available to other than root:wheel and not the ID apache runs under.

- suidperl - I understand that this is not recommended and is not always available.

One idea I had was to create a script that would invoke SUDO on a shell script.  The script would verify the root password against etc/password and then proceed to do what it needs to do.  The SUDO script would be set up to be run by anyone and not require a password prompt since the script itself would verify the password from the environment variable for the edit field on the form that invoked the script.

Am I heading down the right path or is there some other more standard way to do this?

Thanks.....Sam
0
Comment
Question by:elsamman
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
9 Comments
 
LVL 5

Expert Comment

by:g0rath
ID: 9701655

Write a Perl program to be the Authenticator, so If authenticated, then execute sudo application B. Write tracking functions to log all calls to application B, maybe even put time restrictions, and if too many invalid tries from a particular IP, etc then short circuit them to the bit bucket or something of the sort.
0
 

Author Comment

by:elsamman
ID: 9701734
I don't see how that is secure.  If "Application B" which does the work that requires root does not do the authentication then anyone could execute it and bypass the Perl authenticator.  Am I missing something?
0
 
LVL 5

Expert Comment

by:g0rath
ID: 9702006
You make Application B inaccessable via the internet. Read the Env vars to see if someone attempted a POST or a GET and Deny access is one method.

Another method is to create a secure token that Application B will not work unless it recieves it from the first application.

Place it in a dir that cannot be accessed directly

Deny access to that file directly via conf directives

The method for securing the second application should be a trivial matter.
0
U.S. Department of Agriculture and Acronis Access

With the new era of mobile computing, smartphones and tablets, wireless communications and cloud services, the USDA sought to take advantage of a mobilized workforce and the blurring lines between personal and corporate computing resources.

 
LVL 5

Expert Comment

by:g0rath
ID: 9702010
Using Sudo you have one form of tracking anyways via the sudo logs
0
 

Author Comment

by:elsamman
ID: 9702093
This might be OK in a really secure environment.  I am dealing with a shared hosting environment where anyone could write a piece of Perl code to execute "Application B".  All CGI applications run under the same user (nobody).  I don't really like passing a token since that is almost like embedding a password in a file which as far as I am concerned should never be done.  Anyone with read access to the programs can find the token/password.  If I am going to pass a token I might as well just pass along the password I collect from the user and let application b authenticate.
0
 
LVL 5

Expert Comment

by:g0rath
ID: 9702409
ah, usually a shared access environment you don't really want anyone running a root application anyways. So yes that would require a different approach.

The setup wouldn't make me feel that safe with any of those approaches.

I think you would be heading down the correct path with your original idea. Just use the PAM library or something like that to access the password data to do the verfication.

Looks like you had the right idea all along. :)
0
 
LVL 4

Expert Comment

by:freshair
ID: 9705296
what web server are you using?

if you are using Apache, you can use a .htaccess file to restrict access to the Perl script with username and password. and then put the Perl script in an SHTTPD directory so that all data going through are secure. this way only authenticated users may access the Perl script and everything coming in and out of the script are secured.
0
 
LVL 51

Accepted Solution

by:
ahoffmann earned 500 total points
ID: 9710261
as you already know: suEXEC does not support root.
Apache is safe web server, so only running apache as root itself, which is not recomended, gives you the posibility to run a CGI as root.

Another aproach would be:
  echo 'asroot:x:0:0:alias user for root:/asroot:/usr/bin/tcsh' >>/etc/passwd
then setup apache with suEXEC and allow user asroot to run your CGI (donÄt orget chmod, chown etc.).

Keep in mind that this opens your system for root access.
Also some *nix systems do not support this.
I's not suggest to do it, it's up to you.
0
 

Author Comment

by:elsamman
ID: 9833375
Actually the solution that I am going with is the usual one.  At the end of every thread on this topic the advice of most sages is "use the cron Luke".  In other words find a way not to have to run your cgi script as root.  Write a script that leaves bread crumbs for a cron job to pick up and do the deed.

The most secure way I have found to do this is leave an indicator of what I want done in a mySQL database row.  I use the mysql user password to authenticate.  A cron job comes along every 5 minutes or so and does the deed.  I

 None the less I did not know about the alias trick and am very greatful to have that in my arsenal for future use.

.....Sam
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Smart phones, smart watches, Bluetooth-connected devices—the IoT is all around us. In this article, we take a look at the security implications of our highly connected world.
Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed. Methods exist to extract hashes directly for a live domain however this article describes a process to extract u…
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …

732 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question