suEXEC 지원

시작하기 전에 ¶

시작하기 전에 우선 아파치그룹과 이 문서의 가정을 밝힌다.

먼저 setuid와 setgid 기능이 가능한 유닉스류 운영체제를 사용한다고 가정한다. 모든 명령어 예들도 같은 가정을 한다. suEXEC를 지원하는 다른 플래폼을 사용하다면 설정이 다를 수 있다.

두번째, 당신이 컴퓨터 보안의 기본 개념과 관리에 익숙하다고 가정한다. 여기에는 setuid/setgid 기능과 이들이 시스템과 보안에 미치는 여러 영향에 대한 이해가 포함된다.

세번째, suEXEC 코드의 수정하지않은 버전을 사용한다고 가정한다. 개발자와 여러 베타테스터들은 suEXEC와 관련된 모든 코드를 조심스럽게 조사하고 검사했다. 코드를 간단하게 하고 확실한 안전을 보장하기위해 모든 주의를 기울였다. 이 코드를 수정하면 예상치못한 문제와 새로운 보안 위험이 발생할 수 있다. 보안 프로그래밍에 대해 매우 잘 알고 코드를 살펴보기위해 아파치그룹과 작업을 공유할 의사가 없다면 suEXEC 코드를 수정하지않길 강력히 권한다.

네번째이자 마지막으로, 아파치그룹은 suEXEC를 아파치 기본설치에 포함하지 않기로 결정했다. 결국 관리자가 주의를 기울여서 suEXEC를 설정해야 한다. suEXEC의 여러 설정을 잘 고려한후 관리자는 일반적인 설치방법을 suEXEC를 설치할 수 있다. suEXEC 기능을 사용하는 시스템의 보안을 책임지는 관리자는 이 설정값들을 주의있게 살펴보고 지정해야 한다. 이런 상세한 과정은 suEXEC를 사용할만큼 주의있고 단호한 사람만이 suEXEC를 사용하도록 아파치그룹이 원하기 때문이다.

아직도 사용하길 원하는가? 그런가? 좋다. 이제 시작하자!

suEXEC 보안모델 ¶

suEXEC를 구성하고 설치하기 전에 우리는 보안모델을 먼저 설명한다. 이를 통해 정확히 suEXEC 안에서는 무슨 일이 일어나며 시스템의 보안을 위해 무엇을 조심해야 할지 더 잘 이해할 수 있다.

suEXEC는 아파치 웹서버가 부르는 setuid "wrapper" 프로그램을 기반으로 한다. 이 wrapper는 관리자가 주서버와 다른 userid로 실행하도록 설정한 CGI나 SSI 프로그램에 HTTP 요청이 오면 불린다. 이런 요청이 오면 아파치는 suEXEC wrapper에게 프로그램명과 프로그램을 실행할 사용자와 그룹 ID를 제공한다.

그러면 wrapper는 다음 과정을 통해 성공과 실패를 결정한다. 이 조건중 하나라도 실패하면 프로그램은 실패로 기록되고 오류를 내며 종료한다. 실패하지 않으면 과정을 계속한다:

1. wrapper를 실행하는 사용자가 시스템의 정상적인 사용자인가?

   wrapper를 실행하는 사용자가 실제로 시스템의 사용자인지 확인한다.

2. 적절한 수의 아규먼트로 wrapper를 실행하는가?

   wrapper는 적절한 수의 아규먼트가 있어야만 실행된다. 아파치 웹서버가 이 개수를 안다. wrapper가 적절한 수의 아규먼트를 받지못하면 해킹되었거나 아파치의 suEXEC에 뭔가 문제가 있는 것이다.

3. 이 사용자가 wrapper를 실행하도록 허용되었나?

   이 사용자가 wrapper를 실행하도록 허용되었나? 오직 한 사용자(아파치 사용자)만이 이 프로그램을 실행할 수 있다.

4. 지정한 CGI나 SSI 프로그램이 안전하지않은 계층참조를 가지는가?

   지정한 CGI나 SSI 프로그램이 '/'로 시작하거나 뒷참조 '..'을 가지는가? 이들을 사용할 수 없다. 지정한 CGI/SSI 프로그램은 suEXEC 문서 root (아래 --with-suexec-docroot=DIR 참고) 내에 있어야 한다.

5. 지정한 사용자명이 유효한가?

   지정한 사용자가 존재하는가?

6. 지정한 그룹명이 유효한가?

   지정한 그룹이 존재하는가?

7. 지정한 사용자가 superuser가 아닌가?

   현재 suEXEC는 root가 CGI/SSI 프로그램을 실행할 수 없도록 한다.

8. 지정한 userid가 최소 ID 숫자보다 큰가?

   설정에서 최소 사용자 ID 숫자를 지정한다. 그래서 CGI/SSI 프로그램을 실행할 수 있는 userid의 최소치를 지정할 수 있다. "시스템용" 계정을 제외할때 유용하다.

9. 지정한 그룹이 superuser 그룹이 아닌가?

   현재 suEXEC는 root 그룹이 CGI/SSI 프로그램을 실행할 수 없도록 한다.

10. 지정한 groupid가 최소 ID 숫자보다 큰가?

    설정에서 최소 그룹 ID 숫자를 지정한다. 그래서 CGI/SSI 프로그램을 실행할 수 있는 groupid의 최소치를 지정할 수 있다. "시스템용" 그룹을 제외할때 유용하다.

11. wrapper가 성공적으로 지정한 사용자와 그룹이 될 수 있는가?

    이 단계에서 프로그램은 setuid와 setgid 호출을 하여 지정한 사용자와 그룹이 된다. 또, 그룹 접근목록은 사용자가 해당된 모든 그룹으로 초기화된다.

12. CGI/SSI 프로그램이 있는 디렉토리로 디렉토리를 변경할 수 있는가?

    디렉토리가 존재하지 않다면 파일이 있을 수 없다. 이곳으로 디렉토리를 변경할 수 없다면 디렉토리는 존재하지 않을 것이다.

13. 디렉토리가 아파치 웹공간 안에 있는가?

    서버의 일반적인 부분을 요청할 경우 요청하는 디렉토리가 suEXEC 문서 root 아래 있는가? UserDir을 요청할 경우 요청하는 디렉토리가 suEXEC userdir로 설정한 (suEXEC 설정 옵션 참고) 디렉토리 아래에 있는가?

14. 다른 누구도 디렉토리에 쓰기권한이 없는가?

    디렉토리를 다른 사람에게 열어두길 원하지않는다. 오직 소유자만이 디렉토리 내용을 변경할 수 있다.

15. 지정한 CGI/SSI 프로그램이 존재하는가?

    존재하지않다면 실행할 수도 없다.

16. 다른 누구도 지정한 CGI/SSI 프로그램에 쓰기권한이 없는가?

    소유자외 누구도 CGI/SSI 프로그램을 변경하길 원하지않는다.

17. 지정한 CGI/SSI 프로그램이 setuid나 setgid가 아닌가?

    우리는 프로그램이 다시 UID/GID를 변경하길 원하지않는다.

18. 지정한 사용자/그룹이 프로그램의 사용자/그룹과 같은가?

    사용자가 파일의 소유자인가?

19. 안전한 동작을 위해 프로세스의 환경변수를 청소할 수 있는가?

    suEXEC는 (설정에서 정의한) 안전한 실행 PATH를 잡고, (이것도 설정에서 정의) 안전한 환경변수 목록에 열거된 변수만 남기고 프로세스의 환경변수를 지운다.

20. 성공적으로 지정한 CGI/SSI 프로그램을 실행할 수 있는가?

    여기서 suEXEC가 끝나고 지정한 CGI/SSI 프로그램이 시작한다.

이것이 suEXEC wrapper 보안모델의 표준 동작이다. 다소 엄격하고 CGI/SSI 설계에 새로운 제한이 되지만, 보안을 염두에 두고 한단계씩 조심스럽게 만들어졌다.

이 보안 모델이 서버 설정에 어떤 제한을 주는지와 적절한 suEXEC 설정으로 어떤 보안 위험을 피할 수 있는지에 대해 이 문서의 "다시 한번 조심하라" 절을 참고하라.

suEXEC 구성과 설치 ¶

이제 재미있는 내용이 시작한다.

suEXEC 구성 옵션

--enable-suexec

이 옵션은 기본적으로 설치되거나 활성화되지않는 suEXEC 기능을 활성화한다. APACI가 suEXEC를 받아들이려면 --enable-suexec 옵션외에 --with-suexec-xxxxx 옵션이 최소한 한개 필요하다.

--with-suexec-bin=PATH

suexec 바이너리 경로는 보안상 이유로 서버에 기록되야 한다. 경로 기본값을 무시하려면 이 옵션을 사용한다. 예를 들어 --with-suexec-bin=/usr/sbin/suexec

--with-suexec-caller=UID

보통 아파치를 실행하는 사용자명. 프로그램을 실행할 수 있는 유일한 사용자다.

--with-suexec-userdir=DIR

suEXEC 접근이 허용되는 사용자 홈디렉토리의 하위디렉토리를 지정한다. 이 디렉토리에 있는 모든 실행파일을 사용자의 suEXEC로 실행므로, 모든 프로그램이 "안전해야" 한다. (예를 들어, 값에 "*"이 없는) "간단한" UserDir 지시어를 사용한다면 같은 값을 설정해야 한다. UserDir 지시어가 passwd 파일에 나온 사용자 홈디렉토리와 다르면 suEXEC는 정상적으로 작동하지 않는다. 기본값은 "public_html"이다.
가상호스트들이 각각 다른 UserDir을 사용한다면 모두 한 부모 디렉토리 안에 있도록 정의해야 하고, 그 부모 디렉토리명을 여기 적는다. 이렇게 정의하지 않으면, "~userdir" cgi 요청이 작동하지 않는다!

--with-suexec-docroot=DIR

아파치의 DocumentRoot를 정의한다. 이는 suEXEC가 사용할 수 있는 (UserDirs을 제외한) 유일한 공간이다. 기본 디렉토리는 --datadir 값에 "/htdocs"을 붙인 것이다. 예를 들어 "--datadir=/home/apache"로 구성했다면 suEXEC wrapper는 document root로 "/home/apache/htdocs" 디렉토리를 사용한다.

--with-suexec-uidmin=UID

suEXEC에서 지정가능한 사용자의 최소 UID를 정의한다. 대부분의 시스템에서 500이나 100이 적절하다. 기본값은 100이다.

--with-suexec-gidmin=GID

suEXEC에서 지정가능한 그룹의 최소 GID를 정의한다. 대부분의 시스템에서 100이 적절하므로 이 값이 기본값이다.

--with-suexec-logfile=FILE

모든 suEXEC 작동과 오류를 (감시나 디버깅 목적에 유용한) 기록할 로그파일명을 지정한다. 기본적으로 로그파일의 이름은 "suexec_log"이고 표준 로그파일 디렉토리에 (--logfiledir) 위치한다.

--with-suexec-safepath=PATH

CGI 실행파일에 넘겨질 안전한 PATH 환경변수를 정의한다. 기본값은 "/usr/local/bin:/usr/bin:/bin"이다.

suEXEC wrapper를 컴파일하고 설치하기
--enable-suexec 옵션으로 suEXEC 기능을 가능하게한 경우 make 명령어를 실행하면 suexec 실행파일이 (아파치와 함께) 자동으로 만들어진다.
모든것을 컴파일한 후 make install 명령어를 실행하여 설치할 수 있다. 바이너리파일 suexec는 --sbindir 옵션으로 지정한 디렉토리에 설치된다. 기본 위치는 "/usr/local/apache2/sbin/suexec"이다.
설치 과정에 root 권한이 필요함을 주의하라. wrapper가 사용자 ID를 설정하기위해서는 소유자가 root이고 파일모드로 setuserid 실행비트가 설정되야 한다.

편집증적인 권한설정
suEXEC wrapper는 자신을 실행한 사용자가 구성 옵션 --with-suexec-caller로 지정한 올바른 사용자인지 확인을 하지만, 이 검사 이전에 suEXEC가 사용하는 시스템호출 혹은 라이브러리 함수가 조작되었을 수 있다. 이를 대비하며 일반적으로 좋은 습관이므로 오직 아파치를 실행하는 그룹만이 suEXEC를 실행할 수 있도록 파일시스템 권한을 지정해야 한다.

예를 들어, 웹서버를 다음과 같이 설정하고:

suexec를 "/usr/local/apache2/sbin/suexec"에 설치하였다면, 다음을 실행해야 한다:

그러면 오직 아파치를 실행하는 그룹만이 suEXEC wrapper를 실행할 수 있다.

suEXEC 키고 끄기 ¶

아파치는 시작할때 --sbindir 옵션으로 지정한 디렉토리에서 suexec 파일을 (기본값 "/usr/local/apache2/sbin/suexec") 찾는다. 아파치가 정상적으로 구성된 suEXEC wrapper를 발견하면 오류 로그(error log)에 다음과 같이 출력한다:

서버 시작중에 이런 문구를 없다면 서버는 기대한 장소에서 wrapper 프로그램을 찾지 못했거나, 실행파일이 setuid root로 설치되지않았기 때문일 것이다.

처음으로 suEXEC 기능을 사용하고 싶고 이미 아파치 서버가 실행중이라면, 아파치를 죽이고 다시 시작해야 한다. 간단히 HUP이나 USR1 시그널로 재시작하는 것으로는 충분하지 않다.

suEXEC를 안사용하려면 suexec 파일을 지운후 아파치를 죽이고 재시작해야 한다.

suEXEC 사용하기 ¶

CGI 프로그램 요청의 경우 SuexecUserGroup 지시어를 사용한 가상호스트에 요청을 하였거나 mod_userdir이 요청을 처리하는 경우에만 suEXEC wrapper를 호출한다.

가상호스트:
suEXEC wrapper를 사용하는 한가지 방법은 VirtualHost 정의에 SuexecUserGroup 지시어를 사용하는 것이다. 이 지시어를 주서버 사용자 ID와 다르게 설정하면 CGI 자원의 모든 요청이 <VirtualHost>에서 지정한 User와 Group으로 실행된다. 이 지시어들이 <VirtualHost>에 없으면 주서버 userid를 사용한다.

사용자 디렉토리:
mod_userdir이 요청을 처리한다면 suEXEC wrapper를 호출하여, 요청한 사용자 디렉토리에 해당하는 사용자 ID로 CGI 프로그램을 실행한다. 이 기능이 동작하려면 사용자 ID로 CGI를 실행할 수 있고 스크립트가 위의 보안 검사 항목을 만족해야 한다. 구성 옵션 --with-suexec-userdir을 참고하라.

suEXEC 디버깅하기 ¶

suEXEC wrapper는 로그 정보를 위에서 다룬 --with-suexec-logfile 옵션으로 지정한 파일에 쓴다. wrapper를 올바로 구성하고 설치했다면 어디서 잘못되었는지 이 로그파일와 서버의 error_log를 살펴봐라.

다시 한번 조심하라: 경고와 예제 ¶

주의! 이 섹션은 완전하지 않을 수 있다. 아파치그룹의 온라인 문서에서 이 문서의 최신판을 참고하라.

wrapper가 서버 설정을 제약하는 몇가지 흥미로운 점이 있다. suEXEC와 관련된 "버그"를 보고하기 전에 이들을 살펴보길 바란다.

• suEXEC 제약 사항
• 디렉토리 구조 제한

  보안과 효율성을 위해 모든 suEXEC 요청은 가상호스트의 경우 최상위 document root 혹은 userdir 요청의 경우 최상위 개인 document root 안에서 발생해야 한다. 예를 들어, 가상호스트 네개를 설정했다면 가상호스트에서 suEXEC를 이용하기위해 가상호스트의 document root를 주 아파치 문서 계층구조 밖에 설정할 필요가 있다. (예제는 다음에.)

• suEXEC의 PATH 환경변수

  변경하면 위험할 수 있다. 여기에 포함하는 모든 경로가 믿을 수 있는 디렉토리인지 확인하라. 이 지구상의 누군가가 그곳에 있는 트로이목마를 실행하길 원하지 않을 것이다.

• suEXEC 코드 수정하기

  반복해서 말하지만, 당신이 무엇을 하는지 모르고 시도한다면 큰 문제가 발생할 수 있다. 어떤 경우에도 수정하지마라.