suEXEC 기능은 아파치가 CGI와 SSI 프로그램을 웹서버를 실행한 사용자 ID가 아닌 다른 사용자 ID로 실행하도록 한다. 보통 CGI나 SSI 프로그램을 실행하면 웹서버를 실행한 사용자와 같은 사용자로 실행한다.
이 기능을 적절히 사용하면 사용자가 직접 CGI나 SSI 프로그램을 개발하고 실행할때 발생할 수 있는 보안위험을 상당히 줄일 수 있다. 그러나 suEXEC가 부적절하게 설정되면 많은 문제와 컴퓨터에 새로운 보안 허점을 만들 수 있다. 만약 setuid root 프로그램과 이런 프로그램의 보안 문제에 생소하다면 suEXEC를 사용하지않길 진심으로 바란다.
시작하기 전에 우선 아파치그룹과 이 문서의 가정을 밝힌다.
먼저 setuid와 setgid 기능이 가능한 유닉스류 운영체제를 사용한다고 가정한다. 모든 명령어 예들도 같은 가정을 한다. suEXEC를 지원하는 다른 플래폼을 사용하다면 설정이 다를 수 있다.
두번째, 당신이 컴퓨터 보안의 기본 개념과 관리에 익숙하다고 가정한다. 여기에는 setuid/setgid 기능과 이들이 시스템과 보안에 미치는 여러 영향에 대한 이해가 포함된다.
세번째, suEXEC 코드의 수정하지않은 버전을 사용한다고 가정한다. 개발자와 여러 베타테스터들은 suEXEC와 관련된 모든 코드를 조심스럽게 조사하고 검사했다. 코드를 간단하게 하고 확실한 안전을 보장하기위해 모든 주의를 기울였다. 이 코드를 수정하면 예상치못한 문제와 새로운 보안 위험이 발생할 수 있다. 보안 프로그래밍에 대해 매우 잘 알고 코드를 살펴보기위해 아파치그룹과 작업을 공유할 의사가 없다면 suEXEC 코드를 수정하지않길 강력히 권한다.
네번째이자 마지막으로, 아파치그룹은 suEXEC를 아파치 기본설치에 포함하지 않기로 결정했다. 결국 관리자가 주의를 기울여서 suEXEC를 설정해야 한다. suEXEC의 여러 설정을 잘 고려한후 관리자는 일반적인 설치방법을 suEXEC를 설치할 수 있다. suEXEC 기능을 사용하는 시스템의 보안을 책임지는 관리자는 이 설정값들을 주의있게 살펴보고 지정해야 한다. 이런 상세한 과정은 suEXEC를 사용할만큼 주의있고 단호한 사람만이 suEXEC를 사용하도록 아파치그룹이 원하기 때문이다.
아직도 사용하길 원하는가? 그런가? 좋다. 이제 시작하자!
suEXEC를 구성하고 설치하기 전에 우리는 보안모델을 먼저 설명한다. 이를 통해 정확히 suEXEC 안에서는 무슨 일이 일어나며 시스템의 보안을 위해 무엇을 조심해야 할지 더 잘 이해할 수 있다.
suEXEC는 아파치 웹서버가 부르는 setuid "wrapper" 프로그램을 기반으로 한다. 이 wrapper는 관리자가 주서버와 다른 userid로 실행하도록 설정한 CGI나 SSI 프로그램에 HTTP 요청이 오면 불린다. 이런 요청이 오면 아파치는 suEXEC wrapper에게 프로그램명과 프로그램을 실행할 사용자와 그룹 ID를 제공한다.
그러면 wrapper는 다음 과정을 통해 성공과 실패를 결정한다. 이 조건중 하나라도 실패하면 프로그램은 실패로 기록되고 오류를 내며 종료한다. 실패하지 않으면 과정을 계속한다:
wrapper를 실행하는 사용자가 실제로 시스템의 사용자인지 확인한다.
wrapper는 적절한 수의 아규먼트가 있어야만 실행된다. 아파치 웹서버가 이 개수를 안다. wrapper가 적절한 수의 아규먼트를 받지못하면 해킹되었거나 아파치의 suEXEC에 뭔가 문제가 있는 것이다.
이 사용자가 wrapper를 실행하도록 허용되었나? 오직 한 사용자(아파치 사용자)만이 이 프로그램을 실행할 수 있다.
지정한 CGI나 SSI 프로그램이 '/'로 시작하거나 뒷참조
'..'을 가지는가? 이들을 사용할 수 없다. 지정한 CGI/SSI
프로그램은 suEXEC 문서 root (아래
--with-suexec-docroot=DIR 참고)
내에 있어야 한다.
지정한 사용자가 존재하는가?
지정한 그룹이 존재하는가?
현재 suEXEC는 root가 CGI/SSI
프로그램을 실행할 수 없도록 한다.
설정에서 최소 사용자 ID 숫자를 지정한다. 그래서 CGI/SSI 프로그램을 실행할 수 있는 userid의 최소치를 지정할 수 있다. "시스템용" 계정을 제외할때 유용하다.
현재 suEXEC는 root 그룹이 CGI/SSI
프로그램을 실행할 수 없도록 한다.
설정에서 최소 그룹 ID 숫자를 지정한다. 그래서 CGI/SSI 프로그램을 실행할 수 있는 groupid의 최소치를 지정할 수 있다. "시스템용" 그룹을 제외할때 유용하다.
이 단계에서 프로그램은 setuid와 setgid 호출을 하여 지정한 사용자와 그룹이 된다. 또, 그룹 접근목록은 사용자가 해당된 모든 그룹으로 초기화된다.
디렉토리가 존재하지 않다면 파일이 있을 수 없다. 이곳으로 디렉토리를 변경할 수 없다면 디렉토리는 존재하지 않을 것이다.
서버의 일반적인 부분을 요청할 경우 요청하는 디렉토리가 suEXEC 문서 root 아래 있는가? UserDir을 요청할 경우 요청하는 디렉토리가 suEXEC userdir로 설정한 (suEXEC 설정 옵션 참고) 디렉토리 아래에 있는가?
디렉토리를 다른 사람에게 열어두길 원하지않는다. 오직 소유자만이 디렉토리 내용을 변경할 수 있다.
존재하지않다면 실행할 수도 없다.
소유자외 누구도 CGI/SSI 프로그램을 변경하길 원하지않는다.
우리는 프로그램이 다시 UID/GID를 변경하길 원하지않는다.
사용자가 파일의 소유자인가?
suEXEC는 (설정에서 정의한) 안전한 실행 PATH를 잡고, (이것도 설정에서 정의) 안전한 환경변수 목록에 열거된 변수만 남기고 프로세스의 환경변수를 지운다.
여기서 suEXEC가 끝나고 지정한 CGI/SSI 프로그램이 시작한다.
이것이 suEXEC wrapper 보안모델의 표준 동작이다. 다소 엄격하고 CGI/SSI 설계에 새로운 제한이 되지만, 보안을 염두에 두고 한단계씩 조심스럽게 만들어졌다.
이 보안 모델이 서버 설정에 어떤 제한을 주는지와 적절한 suEXEC 설정으로 어떤 보안 위험을 피할 수 있는지에 대해 이 문서의 "다시 한번 조심하라" 절을 참고하라.
이제 재미있는 내용이 시작한다.
suEXEC 구성 옵션
--enable-suexec--enable-suexec 옵션외에
--with-suexec-xxxxx 옵션이 최소한 한개
필요하다.--with-suexec-bin=PATHsuexec 바이너리 경로는 보안상 이유로
서버에 기록되야 한다. 경로 기본값을 무시하려면 이 옵션을
사용한다. 예를 들어
--with-suexec-bin=/usr/sbin/suexec--with-suexec-caller=UID--with-suexec-userdir=DIR--with-suexec-docroot=DIR--datadir 값에 "/htdocs"을 붙인 것이다.
예를 들어 "--datadir=/home/apache"로
구성했다면 suEXEC wrapper는 document root로
"/home/apache/htdocs" 디렉토리를 사용한다.--with-suexec-uidmin=UID--with-suexec-gidmin=GID--with-suexec-logfile=FILE--logfiledir) 위치한다.--with-suexec-safepath=PATHsuEXEC 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를 실행할 수 있다.
아파치는 시작할때 --sbindir 옵션으로 지정한
디렉토리에서 suexec 파일을 (기본값
"/usr/local/apache2/sbin/suexec") 찾는다. 아파치가
정상적으로 구성된 suEXEC wrapper를 발견하면 오류 로그(error
log)에 다음과 같이 출력한다:
서버 시작중에 이런 문구를 없다면 서버는 기대한 장소에서 wrapper 프로그램을 찾지 못했거나, 실행파일이 setuid root로 설치되지않았기 때문일 것이다.
처음으로 suEXEC 기능을 사용하고 싶고 이미 아파치 서버가 실행중이라면, 아파치를 죽이고 다시 시작해야 한다. 간단히 HUP이나 USR1 시그널로 재시작하는 것으로는 충분하지 않다.
suEXEC를 안사용하려면 suexec 파일을 지운후
아파치를 죽이고 재시작해야 한다.
CGI 프로그램 요청의 경우
가상호스트:
suEXEC wrapper를
사용하는 한가지 방법은
사용자 디렉토리:
--with-suexec-userdir을 참고하라.
suEXEC wrapper는 로그 정보를 위에서 다룬
--with-suexec-logfile 옵션으로 지정한 파일에
쓴다. wrapper를 올바로 구성하고 설치했다면 어디서 잘못되었는지
이 로그파일와 서버의 error_log를 살펴봐라.
주의! 이 섹션은 완전하지 않을 수 있다. 아파치그룹의 온라인 문서에서 이 문서의 최신판을 참고하라.
wrapper가 서버 설정을 제약하는 몇가지 흥미로운 점이 있다. suEXEC와 관련된 "버그"를 보고하기 전에 이들을 살펴보길 바란다.
보안과 효율성을 위해 모든 suEXEC 요청은 가상호스트의 경우 최상위 document root 혹은 userdir 요청의 경우 최상위 개인 document root 안에서 발생해야 한다. 예를 들어, 가상호스트 네개를 설정했다면 가상호스트에서 suEXEC를 이용하기위해 가상호스트의 document root를 주 아파치 문서 계층구조 밖에 설정할 필요가 있다. (예제는 다음에.)
변경하면 위험할 수 있다. 여기에 포함하는 모든 경로가 믿을 수 있는 디렉토리인지 확인하라. 이 지구상의 누군가가 그곳에 있는 트로이목마를 실행하길 원하지 않을 것이다.
반복해서 말하지만, 당신이 무엇을 하는지 모르고 시도한다면 큰 문제가 발생할 수 있다. 어떤 경우에도 수정하지마라.