Setuid security model

The suEXEC security model goes like this:

  1. Was the wrapper called with the proper number of arguments?
    The wrapper will only execute if it is given the proper number of arguments. The proper argument format is known to the Apache web server. If the wrapper is not receiving the proper number of arguments, it is either being hacked, or there is something wrong with the suEXEC portion of your Apache binary.
  2. Is the user executing this wrapper a valid user of this system?
    This is to ensure that the user executing the wrapper is truly a user of the system.
  3. Is this valid user allowed to run the wrapper?
    Is this user the user allowed to run this wrapper? Only one user (the Apache user) is allowed to execute this program.
  4. Does the program file exist?
  5. Does the program directory exist?

 

 

 

 

  1. Was the wrapper called with the proper number of arguments?
    The wrapper will only execute if it is given the proper number of arguments. The proper argument format is known to the Apache web server. If the wrapper is not receiving the proper number of arguments, it is either being hacked, or there is something wrong with the suEXEC portion of your Apache binary.
  2. Is the user executing this wrapper a valid user of this system?
    This is to ensure that the user executing the wrapper is truly a user of the system.
  3. Is this valid user allowed to run the wrapper?
    Is this user the user allowed to run this wrapper? Only one user (the Apache user) is allowed to execute this program.
  4. Does the target program have an unsafe hierarchical reference?
    Does the target program contain a leading '/' or have a '..' backreference? These are not allowed; the target program must reside within the Apache webspace.
  5. Is the target user name valid?
    Does the target user exist?
  6. Is the target group name valid?
    Does the target group exist?
  7. Is the target user NOT superuser?
    Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
  8. Is the target userid ABOVE the minimum ID number?
    The minimum user ID number is specified during configuration. This allows you to set the lowest possible userid that will be allowed to execute CGI/SSI programs. This is useful to block out "system" accounts.
  9. Is the target group NOT the superuser group?
    Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs.
  10. Is the target groupid ABOVE the minimum ID number?
    The minimum group ID number is specified during configuration. This allows you to set the lowest possible groupid that will be allowed to execute CGI/SSI programs. This is useful to block out "system" groups.
  11. Can the wrapper successfully become the target user and group?
    Here is where the program becomes the target user and group via setuid and setgid calls. The group access list is also initialized with all of the groups of which the user is a member.
  12. Does the directory in which the program resides exist?
    If it doesn't exist, it can't very well contain files.
  13. Is the directory within the Apache webspace?
    If the request is for a regular portion of the server, is the requested directory within the server's document root? If the request is for a UserDir, is the requested directory within the user's document root?
  14. Is the directory NOT writable by anyone else?
    We don't want to open up the directory to others; only the owner user may be able to alter this directories contents.
  15. Does the target program exist?
    If it doesn't exists, it can't very well be executed.
  16. Is the target program NOT writable by anyone else?
    We don't want to give anyone other than the owner the ability to change the program.
  17. Is the target program NOT setuid or setgid?
    We do not want to execute programs that will then change our UID/GID again.
  18. Is the target user/group the same as the program's user/group?
    Is the user the owner of the file?
  19. Can we successfully clean the process environment to ensure safe operations?
    suEXEC cleans the process' environment by establishing a safe execution PATH (defined during configuration), as well as only passing through those variables whose names are listed in the safe environment list (also created during configuration).
  20. Can we successfully become the target program and execute?
    Here is where suEXEC ends and the target program begins.

     

Here are specific things that we must test to make sure that the suexec-idx patch is performing without some gaping security hole.

  • Check the PATH environment variable attack.
  • Check running from the command line with argument lists that don't match the expected format.
  • Check running from the non-authorized user.
  • Try giving ".." sequences in the command being executed.
  • Check to make sure that normal user scripts don't trigger the redirect flag.
  • Check to see if a normal user can setup a redirect but have the target of the redirect be a -set script
  • Check to see that -set scripts are properly recognized
  • Check to see that non-set scripts are properly recognized
  • Check to see that setuid scripts are disabled when the "SuexecAllowSet" configuration in Apache is setup that way.
  • Check to see that REQUIRED_GROUP{1,2} work properly.
  • Check to see that setuid scripts fail when: (1) prog_dir is writeable by group or other, (2) prog_dir is not owned by the setuid uid/gid, (3) prog_file is a symlink (depending on the configuration), (4) prog_file is writeable by group or others, (5) prog_file is setuid or setgid, (6) prog_file is not owned by the setuid uid/gid.
  • Check to see that scripts without execute permission are caught in suexec and not by an exec failure.
  • Check to make sure uids under UID_MIN and 0 are not allowed to run.
  • Check to make sure gids under GID_MIN and 0 are not allowed to run.
  • Check to see if scripts outside the user's home directory are disallowed.
  • Check to see if setuid redirect scripts outside of REDIRECT_SCRIPT_DIR are disallowed.
  • Check to make sure the directory checking does not let people through when the directories do not exist.
  • Check to see that he environment is cleaned on setuid scripts.