www/apache
www/apache
1
0
Fork 0
mirror of https://github.com/apache/httpd.git synced 2025-06-01 23:21:45 +03:00
Code
apache/docs/manual/suexec.xml.ko
André Malo cb15ea3519 update revision info for the Korean files 
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@103107 13f79535-47bb-0310-9956-ffa450edef68
2004-03-23 18:26:12 +00:00

498 lines
17 KiB
XML
Raw Blame History

<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
<!-- English Revision: 1.7 (outdated: 1.13) -->
<!--
Copyright 2003-2004 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="suexec.xml.meta">
<title>suEXEC 지원</title>
<summary>
<p><strong>suEXEC</strong> 기능은 아파치가 <strong>CGI</strong>와
<strong>SSI</strong> 프로그램을 웹서버를 실행한 사용자 ID가
아닌 다른 사용자 ID로 실행하도록 한다. 보통 CGI나 SSI 프로그램을
실행하면 웹서버를 실행한 사용자와 같은 사용자로 실행한다.</p>
<p>이 기능을 적절히 사용하면 사용자가 직접 CGI나 SSI 프로그램을
개발하고 실행할때 발생할 수 있는 보안위험을 상당히 줄일
수 있다. 그러나 suEXEC가 부적절하게 설정되면 많은 문제와
컴퓨터에 새로운 보안 허점을 만들 수 있다. 만약 setuid root
프로그램과 이런 프로그램의 보안 문제에 생소하다면 suEXEC를
사용하지않길 진심으로 바란다.</p>
</summary>
<section id="before"><title>시작하기 전에</title>
<p>시작하기 전에 우선 아파치그룹과 이 문서의 가정을 밝힌다.</p>
<p>먼저 <strong>setuid</strong>와 <strong>setgid</strong>
기능이 가능한 유닉스류 운영체제를 사용한다고 가정한다. 모든
명령어 예들도 같은 가정을 한다. suEXEC를 지원하는 다른 플래폼을
사용하다면 설정이 다를 수 있다.</p>
<p>두번째, 당신이 컴퓨터 보안의 기본 개념과 관리에 익숙하다고
가정한다. 여기에는 <strong>setuid/setgid</strong> 기능과
이들이 시스템과 보안에 미치는 여러 영향에 대한 이해가 포함된다.</p>
<p>세번째, suEXEC 코드의 <strong>수정하지않은</strong>
버전을 사용한다고 가정한다. 개발자와 여러 베타테스터들은
suEXEC와 관련된 모든 코드를 조심스럽게 조사하고 검사했다.
코드를 간단하게 하고 확실한 안전을 보장하기위해 모든 주의를
기울였다. 이 코드를 수정하면 예상치못한 문제와 새로운 보안
위험이 발생할 수 있다. 보안 프로그래밍에 대해 매우 잘 알고
코드를 살펴보기위해 아파치그룹과 작업을 공유할 의사가 없다면
suEXEC 코드를 수정하지않길 <strong>강력히</strong> 권한다.</p>
<p>네번째이자 마지막으로, 아파치그룹은 suEXEC를 아파치
기본설치에 포함하지 <strong>않기로</strong> 결정했다. 결국
관리자가 주의를 기울여서 suEXEC를 설정해야 한다. suEXEC의
여러 설정을 잘 고려한후 관리자는 일반적인 설치방법을 suEXEC를
설치할 수 있다. suEXEC 기능을 사용하는 시스템의 보안을 책임지는
관리자는 이 설정값들을 주의있게 살펴보고 지정해야 한다.
이런 상세한 과정은 suEXEC를 사용할만큼 주의있고 단호한
사람만이 suEXEC를 사용하도록 아파치그룹이 원하기 때문이다.</p>
<p>아직도 사용하길 원하는가? 그런가? 좋다. 이제 시작하자!</p>
</section>
<section id="model"><title>suEXEC 보안모델</title>
<p>suEXEC를 구성하고 설치하기 전에 우리는 보안모델을 먼저
설명한다. 이를 통해 정확히 suEXEC 안에서는 무슨 일이 일어나며
시스템의 보안을 위해 무엇을 조심해야 할지 더 잘 이해할 수
있다.</p>
<p><strong>suEXEC</strong>는 아파치 웹서버가 부르는 setuid
"wrapper" 프로그램을 기반으로 한다. 이 wrapper는 관리자가
주서버와 다른 userid로 실행하도록 설정한 CGI나 SSI 프로그램에
HTTP 요청이 오면 불린다. 이런 요청이 오면 아파치는 suEXEC
wrapper에게 프로그램명과 프로그램을 실행할 사용자와 그룹
ID를 제공한다.</p>
<p>그러면 wrapper는 다음 과정을 통해 성공과 실패를 결정한다.
이 조건중 하나라도 실패하면 프로그램은 실패로 기록되고 오류를
내며 종료한다. 실패하지 않으면 과정을 계속한다:</p>
<ol>
<li>
<strong>적절한 수의 아규먼트로 wrapper를 실행하는가?</strong>
<p class="indent">
wrapper는 적절한 수의 아규먼트가 있어야만 실행된다.
아파치 웹서버가 이 개수를 안다. wrapper가 적절한 수의
아규먼트를 받지못하면 해킹되었거나 아파치의 suEXEC에
뭔가 문제가 있는 것이다.
</p>
</li>
<li>
<strong>wrapper를 실행하는 사용자가 시스템의 정상적인
사용자인가?</strong>
<p class="indent">
wrapper를 실행하는 사용자가 실제로 시스템의 사용자인지
확인한다.
</p>
</li>
<li>
<strong>이 사용자가 wrapper를 실행하도록 허용되었나?</strong>
<p class="indent">
이 사용자가 wrapper를 실행하도록 허용되었나? 오직
한 사용자(아파치 사용자)만이 이 프로그램을 실행할
수 있다.
</p>
</li>
<li>
<strong>지정한 프로그램이 안전하지않은 계층참조를 가지는가?</strong>
<p class="indent">
지정한 프로그램이 '/'로 시작하거나 뒷참조 '..'을 가지는가?
이들을 사용할 수 없다. 지정한 프로그램은 아파치 웹공간내에
있어야 한다.
</p>
</li>
<li>
<strong>지정한 사용자명이 유효한가?</strong>
<p class="indent">
지정한 사용자가 존재하는가?
</p>
</li>
<li>
<strong>지정한 그룹명이 유효한가?</strong>
<p class="indent">
지정한 그룹이 존재하는가?
</p>
</li>
<li>
<strong>지정한 사용자가 superuser가 <em>아닌가</em>?</strong>
<p class="indent">
현재 suEXEC는 'root'가 CGI/SSI 프로그램을 실행할 수
없도록 한다.
</p>
</li>
<li>
<strong>지정한 userid가 최소 ID 숫자보다 <em>큰가</em>?</strong>
<p class="indent">
설정에서 최소 사용자 ID 숫자를 지정한다. 그래서 CGI/SSI
프로그램을 실행할 수 있는 userid의 최소치를 지정할
수 있다. "시스템용" 계정을 제외할때 유용하다.
</p>
</li>
<li>
<strong>지정한 그룹이 superuser 그룹이 <em>아닌가</em>?</strong>
<p class="indent">
현재 suEXEC는 'root' 그룹이 CGI/SSI 프로그램을 실행할
수 없도록 한다.
</p>
</li>
<li>
<strong>지정한 groupid가 최소 ID 숫자보다 <em>큰가</em>?</strong>
<p class="indent">
설정에서 최소 그룹 ID 숫자를 지정한다. 그래서 CGI/SSI
프로그램을 실행할 수 있는 groupid의 최소치를 지정할
수 있다. "시스템용" 그룹을 제외할때 유용하다.
</p>
</li>
<li>
<strong>wrapper가 성공적으로 지정한 사용자와 그룹이
될 수 있는가?</strong>
<p class="indent">
이 단계에서 프로그램은 setuid와 setgid 호출을 하여
지정한 사용자와 그룹이 된다. 또, 그룹 접근목록은
사용자가 해당된 모든 그룹으로 초기화된다.
</p>
</li>
<li>
<strong>프로그램이 있는 디렉토리가 존재하나?</strong>
<p class="indent">
존재하지 않다면 파일이 있을 수 없다.
</p>
</li>
<li>
<strong>디렉토리가 아파치 웹공간 안에 있는가?</strong>
<p class="indent">
서버의 일반적인 부분을 요청할 경우 요청하는 디렉토리가
서버의 문서 root 아래 있는가? UserDir을 요청할 경우
요청하는 디렉토리가 사용자 문서 root 아래 있는가?
</p>
</li>
<li>
<strong>다른 누구도 디렉토리에 쓰기권한이 <em>없는가</em>?</strong>
<p class="indent">
디렉토리를 다른 사람에게 열어두길 원하지않는다. 오직
소유자만이 디렉토리 내용을 변경할 수 있다.
</p>
</li>
<li>
<strong>지정한 프로그램이 존재하는가?</strong>
<p class="indent">
존재하지않다면 실행할 수도 없다.
</p>
</li>
<li>
<strong>다른 누구도 지정한 프로그램에 쓰기권한이
<em>없는가</em>?</strong>
<p class="indent">
소유자외 누구도 프로그램을 변경하길 원하지않는다.
</p>
</li>
<li>
<strong>지정한 프로그램이 setuid나 setgid가 <em>아닌가</em>?</strong>
<p class="indent">
우리는 프로그램이 다시 UID/GID를 변경하길 원하지않는다.
</p>
</li>
<li>
<strong>지정한 사용자/그룹이 프로그램의 사용자/그룹과 같은가?</strong>
<p class="indent">
사용자가 파일의 소유자인가?
</p>
</li>
<li>
<strong>안전한 동작을 위해 프로세스의 환경변수를 청소할
수 있는가?</strong>
<p class="indent">
suEXEC는 (설정에서 정의한) 안전한 실행 PATH를 잡고,
(이것도 설정에서 정의) 안전한 환경변수 목록에 열거된
변수만 남기고 프로세스의 환경변수를 지운다.
</p>
</li>
<li>
<strong>성공적으로 지정한 프로그램을 실행할 수 있는가?</strong>
<p class="indent">
여기서 suEXEC가 끝나고 지정한 프로그램이 시작한다.
</p>
</li>
</ol>
<p>이것이 suEXEC wrapper 보안모델의 표준 동작이다. 다소
엄격하고 CGI/SSI 설계에 새로운 제한이 되지만, 보안을 염두에
두고 한단계씩 조심스럽게 만들어졌다.</p>
<p>이 보안 모델이 서버 설정에 어떤 제한을 주는지와 적절한
suEXEC 설정으로 어떤 보안 위험을 피할 수 있는지에 대해 이
문서의 <a href="#jabberwock">"다시 한번 조심하라"</a> 절을
참고하라.</p>
</section>
<section id="install"><title>suEXEC 구성과 설치</title>
<p>이제 재미있는 내용이 시작한다.</p>
<p><strong>suEXEC 구성 옵션</strong><br />
</p>
<dl>
<dt><code>--enable-suexec</code></dt>
<dd>이 옵션은 기본적으로 설치되거나 활성화되지않는 suEXEC
기능을 활성화한다. APACI가 suEXEC를 받아들이려면
--enable-suexec 옵션외에 --with-suexec-xxxxx 옵션이 최소한
한개 필요하다.</dd>
<dt><code>--with-suexec-bin=<em>PATH</em></code></dt>
<dd>suexec 바이너리 경로는 보안상 이유로 서버에 기록되야
한다. 경로 기본값을 무시하려면 이 옵션을 사용한다. <em>예를
들어</em> <code>--with-suexec-bin=/usr/sbin/suexec</code></dd>
<dt><code>--with-suexec-caller=<em>UID</em></code></dt>
<dd>보통 아파치를 실행하는 <a
href="mod/mpm_common.html#user">사용자명</a>. 프로그램을
실행할 수 있는 유일한 사용자다.</dd>
<dt><code>--with-suexec-userdir=<em>DIR</em></code></dt>
<dd>suEXEC 접근이 허용되는 사용자 홈디렉토리의 하위디렉토리를
지정한다. 이 디렉토리에 있는 모든 실행파일을 사용자의
suEXEC로 실행므로, 모든 프로그램이 "안전해야" 한다. (예를
들어, 값에 "*"이 없는) "간단한" UserDir 지시어를 사용한다면
같은 값을 설정해야 한다. UserDir 지시어가 passwd 파일에
나온 사용자 홈디렉토리와 다르면 suEXEC는 정상적으로
작동하지 않는다. 기본값은 "public_html"이다.<br />
가상호스트들이 각각 다른 UserDir을 사용한다면 모두 한
부모 디렉토리 안에 있도록 정의해야 하고, 그 부모 디렉토리명을
여기 적는다. <strong>이렇게 정의하지 않으면, "~userdir"
cgi 요청이 작동하지 않는다!</strong></dd>
<dt><code>--with-suexec-docroot=<em>DIR</em></code></dt>
<dd>아파치의 DocumentRoot를 정의한다. 이는 suEXEC가 사용할
수 있는 (UserDirs을 제외한) 유일한 공간이다. 기본 디렉토리는
--datadir 값에 "/htdocs"을 붙인 것이다. <em>예를 들어</em>
"<code>--datadir=/home/apache</code>"로 구성했다면 suEXEC
wrapper는 document root로 "/home/apache/htdocs" 디렉토리를
사용한다.</dd>
<dt><code>--with-suexec-uidmin=<em>UID</em></code></dt>
<dd>suEXEC에서 지정가능한 사용자의 최소 UID를 정의한다.
대부분의 시스템에서 500이나 100이 적절하다. 기본값은
100이다.</dd>
<dt><code>--with-suexec-gidmin=<em>GID</em></code></dt>
<dd>suEXEC에서 지정가능한 그룹의 최소 GID를 정의한다.
대부분의 시스템에서 100이 적절하므로 이 값이 기본값이다.</dd>
<dt><code>--with-suexec-logfile=<em>FILE</em></code></dt>
<dd>모든 suEXEC 작동과 오류를 (감시나 디버깅 목적에 유용한)
기록할 로그파일명을 지정한다. 기본적으로 로그파일의 이름은
"suexec_log"이고 표준 로그파일 디렉토리에 (--logfiledir)
위치한다.</dd>
<dt><code>--with-suexec-safepath=<em>PATH</em></code></dt>
<dd>CGI 실행파일에 넘겨질 안전한 PATH 환경변수를 정의한다.
기본값은 "/usr/local/bin:/usr/bin:/bin"이다.</dd>
</dl>
<p><strong>suEXEC 구성을 점검하라</strong><br />
suEXEC wrapper를 컴파일하고 설치하기 전에 --layout 옵션을
사용하여 설정을 점검할 수 있다.<br />
출력예:</p>
<example>
suEXEC setup:<br />
suexec binary: /usr/local/apache/sbin/suexec<br />
document root: /usr/local/apache/share/htdocs<br />
userdir suffix: public_html<br />
logfile: /usr/local/apache/var/log/suexec_log<br />
safe path: /usr/local/bin:/usr/bin:/bin<br />
caller ID: www<br />
minimum user ID: 100<br />
minimum group ID: 100<br />
</example>
<p><strong>suEXEC wrapper를 컴파일하고 설치하기</strong><br />
--enable-suexec 옵션으로 suEXEC 기능을 가능하게한 경우
"make" 명령어를 실행하면 suexec 실행파일이 (아파치와 함께)
자동으로 만들어진다.<br />
모든것을 컴파일한 후 "make install" 명령어를 실행하여 설치할
수 있다. 바이너리파일 "suexec"는 --sbindir 옵션으로 지정한
디렉토리에 설치된다. 기본 위치는
"/usr/local/apache/sbin/suexec"이다.<br />
설치 과정에 <strong><em>root 권한</em></strong>이 필요함을
주의하라. wrapper가 사용자 ID를 설정하기위해서는 소유자가
<code><em>root</em></code>이고 파일모드로 setuserid 실행비트가
설정되야 한다.</p>
</section>
<section id="enable"><title>suEXEC 키고 끄기</title>
<p>아파치는 시작할때 "sbin" 디렉토리에서 "suexec" 파일을
(기본값 "/usr/local/apache/sbin/suexec") 찾는다. 아파치가
정상적으로 구성된 suEXEC wrapper를 발견하면 error log에
다음과 같이 출력한다:</p>
<example>
[notice] suEXEC mechanism enabled (wrapper: <em>/path/to/suexec</em>)
</example>
<p>서버 시작중에 이런 문구를 없다면 서버는 기대한 장소에서
wrapper 프로그램을 찾지 못했거나, 실행파일이 <em>setuid
root</em>로 설치되지않았기 때문일 것이다.</p>
<p>처음으로 suEXEC 기능을 사용하고 싶고 이미 아파치 서버가
실행중이라면, 아파치를 죽이고 다시 시작해야 한다. 간단히
HUP이나 USR1 시그널로 재시작하는 것으로는 충분하지 않다. </p>
<p>suEXEC를 안사용하려면 "suexec" 파일을 지운후 아파치를
죽이고 재시작해야 한다. </p>
</section>
<section id="usage"><title>suEXEC 사용하기</title>
<p><strong>가상호스트:</strong><br /> suEXEC wrapper를
사용하는 한가지 방법은 <directive
module="core">VirtualHost</directive> 정의에 <directive
module="mod_suexec">SuexecUserGroup</directive> 지시어를
사용하는 것이다. 이 지시어를 주서버 사용자 ID와 다르게
설정하면 CGI 자원의 모든 요청이 <directive
module="core" type="section">VirtualHost</directive>에서
지정한 <em>User</em>와 <em>Group</em>으로 실행된다. 이
지시어들이 <directive module="core"
type="section">VirtualHost</directive>에 없으면 주서버
userid를 사용한다.</p>
<p><strong>사용자 디렉토리:</strong><br />
suEXEC wrapper는 CGI 프로그램을 요청을 받은 사용자가 실행하도록
할 수 있다. 이를 위해 실행하길 원하는 사용자 ID 앞에
"<strong><code>~</code></strong>" 문자를 붙이면 된다. 실행을
위해 해당 사용자는 CGI를 실행할 수 있어야 하고, 스크립트가
위의 <a href="#model">보안 검사</a> 항목을 만족해야 한다.</p>
</section>
<section id="debug"><title>suEXEC 디버깅하기</title>
<p>suEXEC wrapper는 로그 정보를 위에서 다룬 --with-suexec-logfile
옵션으로 지정한 파일에 쓴다. wrapper를 올바로 구성하고 설치했다면
어디서 잘못되었는지 이 로그파일와 서버의 error_log를 살펴봐라.</p>
</section>
<section id="jabberwock"><title>다시 한번 조심하라: 경고와 예제</title>
<p><strong>주의!</strong> 이 섹션은 완전하지 않을 수 있다.
아파치그룹의 <a
href="http://httpd.apache.org/docs-2.1/suexec.html">온라인
문서</a>에서 이 문서의 최신판을 참고하라.</p>
<p>wrapper가 서버 설정을 제약하는 몇가지 흥미로운 점이 있다.
suEXEC와 관련된 "버그"를 보고하기 전에 이들을 살펴보길 바란다.</p>
<ul>
<li><strong>suEXEC 제약 사항</strong></li>
<li>
디렉토리 구조 제한
<p class="indent">
보안과 효율성을 위해 모든 suexec 요청은 가상호스트의
경우 최상위 document root 혹은 userdir 요청의 경우
최상위 개인 document root 안에서 발생해야 한다. 예를
들어, 가상호스트 네개를 설정했다면 가상호스트에서
suEXEC를 이용하기위해 가상호스트의 document root를
주 아파치 문서 계층구조 밖에 설정할 필요가 있다.
(예제는 다음에.)
</p>
</li>
<li>
suEXEC의 PATH 환경변수
<p class="indent">
변경하면 위험할 수 있다. 여기에 포함하는 모든 경로가
<strong>믿을 수 있는</strong> 디렉토리인지 확인하라.
이 지구상의 누군가가 그곳에 있는 트로이목마를 실행하길
원하지 않을 것이다.
</p>
</li>
<li>
suEXEC 코드 수정하기
<p class="indent">
반복해서 말하지만, 당신이 무엇을 하는지 모르고 시도한다면
<strong>큰 문제</strong>가 발생할 수 있다. 어떤 경우에도
수정하지마라.
</p>
</li>
</ul>
</section>
</manualpage>
View Git Blame Copy Permalink