한빛출판네트워크

제공 : 한빛 네트워크
저자 : Mark Petrovic
역자 : 김형욱
원문 : http://www.onjava.com/pub/a/onjava/2007/01/03/discovering-java-security-requirements.html

[이전 기사 보기]
☞ 자바 애플리케이션 보안 요구사항의 발견 - 1

좀 더 복잡한 사례 : Tomcat Web Application의 프로파일링

이제 간단한 예제는 뒤로 제쳐두고 ProfilingSecurityManager를 좀 더 실질적인 일에 사용하도록 해보자. 바로 Tomcat 웹 애플리케이션을 프로파일링(profiling)하는 것인데 Tomcat은 표준 시작 스크립트(startup script)에 –security 옵션을 줌으로써 기본 security manager 하에서 돌아가게 할 수 있다.

$ $CATALINA_HOME/bin/startup.sh -security

startup.sh에 –security 옵션을 주면 $CATALINA_HOME/bin/catalina.sh에 –security 옵션을 주고 호출하게 된다. $CATALINA_HOME/bin/catalina.sh는 Tomcat의 Bootstrap 클래스인 org.apache.catalina.startup.Bootstrap 를 실행시키기 위해 실제로 java를 호출하고 더 나아가 이 경우에는 $CATALINA_HOME/conf/catalina.policy에 명시된 기본 정책(default policy)에 따라 실행되도록 한다. 위 옵션을 통해 Tomcat에 기본으로 장착된 정책에 따라 기본 자바 security manager 하에서 Tomcat을 실행시킬 수 있지만 몇 가지 할 일이 더 있다. ProfilingSecurityManager를 사용하여 웹 애플리케이션을 프로파일링하려면 새로운 Tomcat 시작 스크립트(startup script)를 개발해야 한다. 이 때 이 스크립트는 임시적인 것으로서 오직 프로파일링에만 사용되고 버려질 것이다.

먼저 $CATALINA_HOME/bin/catalina.sh 파일을 백업받은 후에 $CATALINA_HOME/bin/catalina.sh의 앞부분 쉘에 set –x 라는 명령을 삽입하고 Tomcat을 시작하자. 그러면 이 쉘이 수행하는 명령들이 화면에 나타날텐데 그것들을 파일로 저장하면 이게 바로 임시 시작 스크립트(startup script)가 된다. 이제 Tomcat을 멈추고 임시 스크립트를 편집하자. security manager를 ProfilingSecurityManager 로 명시하고 그에 맞게 classpath를 바꾸면 된다.

리눅스 기반의 Tomcat 5.5.17에서 아직 편집하기 전의 임시 시작 스크립트는 아래와 같다. (약간 고치고 형식을 손 봤다)

#!/bin/sh
log=$CATALINA_HOME/logs/catalina.out

/java/jdk/jdk1.5.0_06/bin/java 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.util.logging.config.file=/home/tomcat/tomcat/conf/logging.properties 
-Djava.endorsed.dirs=/home/tomcat/tomcat/common/endorsed 
-classpath :/home/tomcat/tomcat/bin/bootstrap.jar:
/home/tomcat/tomcat/bin/commons-logging-api.jar 
-Djava.security.manager 
-Djava.security.policy==/home/tomcat/tomcat/conf/catalina.policy 
-Dcatalina.base=/home/tomcat/tomcat 
-Dcatalina.home=/home/tomcat/tomcat 
-Djava.io.tmpdir=/home/tomcat/tomcat/temp 
org.apache.catalina.startup.Bootstrap start >> $log 
2>&1 &

ProfilingSecurityManager를 사용하기 위해 편집한 후의 스크립트는 다음과 같다.

#!/bin/sh
log=$CATALINA_HOME/logs/catalina.out
PATHTOPSM=$HOME/lib/psm.jar  # make sure the profiler jar file is here

/java/jdk/jdk1.5.0_06/bin/java 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.util.logging.config.file=/home/tomcat/tomcat/conf/logging.properties 
-Djava.endorsed.dirs=/home/tomcat/tomcat/common/endorsed 
-classpath $PATHTOPSM:/home/tomcat/tomcat/bin/bootstrap.jar:
/home/tomcat/tomcat/bin/commons-logging-api.jar 
-Djava.security.manager=secmgr.manager.ProfilingSecurityManager 
-Djava.security.policy==/home/tomcat/tomcat/conf/catalina.policy 
-Dcatalina.base=/home/tomcat/tomcat 
-Dcatalina.home=/home/tomcat/tomcat 
-Djava.io.tmpdir=/home/tomcat/tomcat/temp 
org.apache.catalina.startup.Bootstrap start >> $log 
2>&1 &

새로운 버전의 스크립트가 달라진 점은 다음과 같다.

1. ProfilingSecurityManager 클래스가 있는 $HOME/lib/psm.jar를 classpath에 추가
2. -Djava.security.manager 파라미터에서 ProfilingSecurityManager를 security manager로 설정

이제 우리는 프로파일링을 시작할 수 있다. 위의 시작 스크립트를 통해 Tomcat을 실행시키자. 그리고 프로덕션 시나리오에서 사용될 코드를 다룰 수 있도록 하면서 웹 애플리케이션을 가동시켜본다. 솔직히 말해서 웹 애플리케이션이 특정 코드를 다루도록 하는 것이 쉬운 일은 아니며 아마도 부분적으로만 가능할 것이다. 이제 Tomcat을 멈춘 후 parsecodebase.pl를 통해 $CATALINA_HOME/logs/catalina.out를 실행시키자. 그러면 아래에서 볼 수 있듯이 처리 결과로서의 규칙들이 policy.txt 파일에 저장된다.

$ parsecodebase.pl < $CATALINA_HOME/logs/catalina.out > policy.txt

ProfilingSecurityManager는 프로파일링 동안에 실행된 코드에 대해서만 규칙을 생성할 수 있다는 사실을 알아두자. 이것은 임의적인 런타임 인스턴스(runtime instance) 에서 이론상 수행될 수 있는 모든 코드 브랜치(code branch)들을 조사하는 식의 클래스 바이트 코드 검사는 아니기 때문이다. 그러한 바이트 코드 분석 방법은 추후에 추가될 수 있는 있겠지만 ProfilingSecurityManager에 의해 행해지는 런타임 분석을 대체하지는 않을 것이다.

Tomcat에 딸려있는 정책 파일인 $CATALINA_HOME/conf/catalina.policy을 살펴보면 Tomcat(“Catalina”)의 시스템 codebase가 모든 플랫폼 퍼미션(permission)을 가지고 있음을 알 수 있을 것이다. 사실 ProfilingSecurityManager는 Tomcat 시스템 클래스에 대한 것으로서 위 정책 파일에 있는 것과 같은 규칙들을 발견하여 다만 좀 정리한 형태로 보여줄 것이다. Tomcat 시스템 클래스에 대해 ProfilingSecurityManager가 발견한 규칙들은 policy.txt 파일로부터 수동으로 제거되어야 한다.

policy.txt 파일에서 Tomcat 시스템 관련 규칙을 제거한 후 남은 규칙들이 우리 제품의 보안정책(security policy)을 위한 출발점이 된다. 이러한 규칙들은 웹 애플리케이션의 보안 요구 사항을 나타내며 각각의 규칙들은 그것들이 무슨 일을 하는지 그리고 애플리케이션의 목적과 부합하는지 여부를 확인하기 위해 소상하게 점검되어야 한다. 만약 이것들이 괜찮다는 확신이 들면 $CATALINA_HOME/conf/catalina.policy를 백업하고 policy.txt로부터 얻은 새로운 드래프트 규칙(draft policy)들을 catalina.policy 파일에 포함시켜라. 그리고 –security 옵션이 붙은 원래의 Tomcat 시작 스크립트(startup script)를 돌아가 테스트를 계속하면 된다.

결론

애플리케이션을 자바 Security Manager를 사용하여 구동시킴으로써 애플리케이션의 코드는 더욱 견고해 질 수 있다. 그리고 보안 정책에 대한 권한(securiy policy right)를 얻는 것이 다소 힘들 수 있지만 대신에 우리가 만든 코드가 미리 기술한 보안 제약 사항에 따라 실행되고 있다는 마음의 평화를 얻을 수 있을 것이다. ProfileingSecurityManager를 사용하면 애플리케이션이 접근을 요청한 자원을 다 볼 수 있으므로 해당 정책 권한(policy right)을 얻는 데 많은 도움을 받을 수 있을 것이다.

참고 자료

• ProfilingSecurityManager와 parsecodebase.pl를 포함한 샘플 코드
• Java Reflection의 기초에 대해 언급한 문서인 Subverting Java Access Protection for Unit Testing
• Tomcat 보안 관련 사항이 추가된 Tomcat 가이드
• Java Permissions list
• 자바 보안 아키텍처 문서

---

저자 Mark Petrovic는 공학자이자 소프트웨어 개발자이다.