suexec allows deleting files which owner is root

Discussion in 'Installation/Configuration' started by xerc, Oct 21, 2009.

  1. xerc

    xerc New Member

    Hi folks,

    I used the Lenny Perfect Server Tutorial to install my server.
    ISPConfig 3.0.1.5

    I use php fastcgi in all sites. My problem was that php was not allowed to write to files in the docroot, even if owner and group are correct (webXX and clientXX), rights of all directories and files were 755. Then I tried 775, and suddenly php was allowed to write in the docroot.

    "That's not so pretty" I thought, so I looked around and found suexec.
    I didn't found a switch in ISPConfig to enable suexec, so I added it manually to my vhost for testing:

    <VirtualHost *:80>
    SuexecUserGroup web13 client4

    Now php could write in the docroot with 755. "Nice" I thought. Until I tested it in the depth:

    First problem:
    -r--r--r-- 1 root root 54 2009-10-21 18:11 test.php

    test.php can be executed, even if owner is root.

    Second Problem:
    test.php can delete files owned by root, even if I set owner of test.php to web13 and group to client4.

    test.php:
    PHP:
    <?php
    unlink
    ("deleteme");
    ?>
    -r--r--r-- 1 web13 client4 54 2009-10-21 18:11 test.php
    -r--r--r-- 1 root root 0 2009-10-21 19:44 deleteme

    Deleting is always possible.

    Why is this possible? I thought suexec would prevent something link this.

    Third problem:
    -rwsr-xr-- 1 root www-data 14K 2009-07-14 22:47 /usr/lib/apache2/suexec

    In http://httpd.apache.org/docs/2.0/suexec.html I read that suexec has to be owned by apache, but here it is owned by root. If I change the owner to www-data, apache won't stat (no suexec wrapper found).

    EDIT:
    When I do "su web13" I stay root, but I get no error.
    /var/log/sulog says:
    SU 10/22 11:21 + pts/1 root-web13
     
    Last edited: Oct 22, 2009
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    There is a checkbox labeled "suxec" in the website settings. Do not edit the vhosts manually!

    test.php must be owned by the user and group of the website and not root. None of your users is able to create files as root, you simply created the file with the root user and so the file has the wrong owner.
     
  3. xerc

    xerc New Member

    Hi,
    i found the checkbox, thanks a lot.

    But why can the phpscript, even if it is owned by web13, delete a file which owner is root? If I install phpshell, I can even start shellscripts as web13 which owner is root, if they lie in the webroot.
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    This depends on the permissions of the file and not just the owner. If you run:

    chwon root:root myfile.sh
    chmod 700 myfile.sh

    then nobody except of the root user itself can modify or delete it.

    But if a file has permissions for another group or even others to modify or run it, the members of the group or others can use or edit the file. Thats theway the linux permission system works.
     
  5. xerc

    xerc New Member

    Hi Till,

    seems like you haven't read my first post completly.

    test.php:
    PHP:
    <?php
    unlink
    ("deleteme");
    ?>
    -r--r--r-- 1 web13 client4 54 2009-10-21 18:11 test.php
    -r-------- 1 root root 0 2009-10-21 19:44 deleteme

    Deleting of file "deleteme" is always possible when I execute test.php in browser.

    That's what it's all about, this should not be possible.
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Seems as you have not read my post properly ;) I told you that test.php has to be owned by the user and group of the website and not root.
     
  7. xerc

    xerc New Member

    :D

    please look at my previous post. There you can see that test.php is owned by web13:client4. So definetly not root.

    Greetings
     
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    And you called the php script trogh the webbrowser and nit not executed it on the shell? Then you must have a serious problem with the linux permission system on your server.

    Please create a php script owned by the web user and group with the following content:

    <?php
    system('whoami');
    ?>
     
  9. xerc

    xerc New Member

    Yes, I called the script from a browser.

    With suexec it says "web13" and I can delete the file owned by root.
    If I deactivate suexec it says "www-data" and i can't delete the file owned by root.
     
  10. giftsnake

    giftsnake New Member

    using suPHP (system('whoami'); shows web1) i can delete files owned by root and permissions 700 also.

    i cant delete files in /var/www/domain.com/ but in web/deletefolder/ (when deletefolder has permissions for web1 to access, but file is still 700 and root!)


    rmdir('folder'); works like a charm too!
     
    Last edited: Oct 22, 2009
  11. till

    till Super Moderator Staff Member ISPConfig Developer

    I'am researching the problem. No Idea at the moment what might cause this.
     
  12. till

    till Super Moderator Staff Member ISPConfig Developer

    Which Linux distribution do you use?
     
  13. giftsnake

    giftsnake New Member

    for me its debian lenny, according to perfect setup, no special stuff done with php

    maybe: is the virtual user webx chrooted into /var/www/domain/ and the web folder is the users home?
    i think i can delete files in my home too, even if they belong to root...
     
    Last edited: Oct 22, 2009
  14. till

    till Super Moderator Staff Member ISPConfig Developer

    The interesting thing I found out in the meanwhile is, if you login as root, then su to web1 it is possible to delete a file owned by root. But if you change the shell in /etc/passwd from /bin/false to /bin/sh for user webx, its not possible anymore. But the php scripts are still able to delete root files. I'am using debian lenny with latest updates too on my test server. Also suexec is not reporting anymore if a file is owned by the wrong user which it should do too.

    Which jailkit version do you use?
     
  15. dxr

    dxr New Member

    Hi,

    I will show an example:

    2 shells, 1 root shell and another user shell.

    I added ispconfig user with correct privileges:

    Code:
    $ ssh [email protected]
    Password:
    Last login: Thu Oct 22 23:18:37 2009 from gea.univers.es
    ispconfig@gea ~ $ id
    uid=1005(ispconfig) gid=1018(ispconfig) grupos=1018(ispconfig)
    ispconfig@gea ~ $ ls -lah
    total 0
    drwx------  2 ispconfig ispconfig  48 oct 22 23:18 .
    drwxr-xr-x 11 root      root      280 oct 22 23:18 ..
    ispconfig@gea ~ $ 
    
    I created a root file in ispconfig's HOME

    Code:
    gea ~ # cd /home/ispconfig/
    gea ispconfig # ls -lah
    total 0
    drwx------  2 ispconfig ispconfig  48 oct 22 23:18 .
    drwxr-xr-x 11 root      root      280 oct 22 23:18 ..
    gea ispconfig # touch root_file
    gea ispconfig #
    
    And i can delete it as ispconfig user because it is a root file IN ispconfig's HOME

    Code:
    ispconfig@gea ~ $ ls -lah
    total 0
    drwx------  2 ispconfig ispconfig  80 oct 22 23:19 .
    drwxr-xr-x 11 root      root      280 oct 22 23:18 ..
    -rw-r--r--  1 root      root        0 oct 22 23:19 root_file
    ispconfig@gea ~ $ rm -rf root_file
    ispconfig@gea ~ $ ls -lah
    total 0
    drwx------  2 ispconfig ispconfig  48 oct 22 23:19 .
    drwxr-xr-x 11 root      root      280 oct 22 23:18 ..
    ispconfig@gea ~ $
    
    BUT, if we change the privileges for this directory (home)

    Code:
    gea ispconfig # chown root:root /home/ispconfig/ && chmod 755 /home/ispconfig/
    gea ispconfig # touch root_file
    gea ispconfig #
    
    We can not delete file in any directory if we are not owner

    Code:
    ispconfig@gea ~ $ ls -lah
    total 0
    drwxr-xr-x  2 root root  80 oct 22 23:19 .
    drwxr-xr-x 11 root root 280 oct 22 23:18 ..
    -rw-r--r--  1 root root   0 oct 22 23:19 root_file
    ispconfig@gea ~ $ rm -rf root_file
    rm: no se puede borrar «root_file»: Permiso denegado
    ispconfig@gea ~ $
    
    If you are the directory owner, you control the entire content. It's not a bug, it is unix privileges.
     
    Last edited: Oct 22, 2009

Share This Page