The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Prevent users from reading each others webroots when using PHP system functions?

Discussion in 'Security' started by Sonician, Aug 23, 2011.

  1. Sonician

    Sonician Registered

    Joined:
    May 28, 2011
    Messages:
    0
    Likes Received:
    0
    Trophy Points:
    0
    Hi!

    What would be the best way to prevent system functions such as shell_exec, exec and so on from acessing other users webroots, besides actually disabling them? suPHP + open_basedir aren't compatible as it seems.

    Any suggestions on what route to take?

    /Sonician
     
  2. texo

    texo Well-Known Member

    Joined:
    Mar 28, 2007
    Messages:
    143
    Likes Received:
    0
    Trophy Points:
    16
    I'm testing 1h.com's HIVE on some of my servers, and it's working really well. One of the things it does is employ "a chroot mechanism where each user is limited to its own directory". So far, it's looking really good.
     
  3. alphawolf50

    alphawolf50 Well-Known Member

    Joined:
    Apr 28, 2011
    Messages:
    186
    Likes Received:
    2
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    The best option is to disable those functions if you can find a work-around. Another option may seem a little crazy, but this is what I've done with mod_fcgid + suEXEC:

    1. Edit /etc/group so that "nobody" is in each web users's group. (Only web users!!) So:

    useracct:x:537:useracct,nobody

    2. Restart Apache

    3. Modify permissions (for each account):

    # cd /home/useracct/public_html/
    # find . -type d -exec chmod 710 {} \;
    # find . -type f -exec chmod 640 {} \;
    # find . -type f -name "*.php" -exec chmod 600 {} \;

    The above will set:
    1. read/write/traverse on all directories for the owner, and traverse only for the group (needed because "nobody" is in the group), but no rights for "everyone".
    2. read/write for all files for owner, read-only for group (so apache can serve image, html, css, etc), and no rights for "everyone"
    3. read/write for PHP files for owner, and absolutely no rights for anyone else. This makes it impossible for apache to ever read a php config script directly and expose your passwords.
    As always, test this somewhere unimportant before doing it live. You'll also want to check the permissions within the users home directory and make sure the user's group doesn't have access to places it shouldn't.
     
  4. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    I wouldn't recommend editing /etc/group (or /etc/passwd) manually in any way at all. You can corrupt the file and then no users will be able to function on the system.

    Please note that any steps that can possibly put your system into a state of dysfunction along with customizing to the point it doesn't fall under the typical cPanel setup would mean we no longer support that system. If you choose to follow recommendations such as the above without considering this caveat and then break the system, we cannot restore those settings for you. You would want to make certain to have full backups that can be restored to a clean system that hasn't been fundamentally altered.
     
  5. alphawolf50

    alphawolf50 Well-Known Member

    Joined:
    Apr 28, 2011
    Messages:
    186
    Likes Received:
    2
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    I did say that the best option was just to disable those functions. :) But perhaps some additional warning was warranted.

    If you break it you're on your own -- test in your own test environment before going live -- and if you don't know how to revert these changes, you should not make them!

    Re: Editing /etc/group - I did it manually because it was quicker for multiple accounts, but there is the safer command line option:
    (replace webacct with the account)
    Code:
    # useradd -G {webacct} nobody
    
    As said above -- if you do any of this you are on your own re: support.
     
Loading...

Share This Page