자바 시큐리티에 대한 고찰

임 영 주
서울특별시 관악구
서울대학교 물리학과
E-mail : cogito@newton.snu.ac.kr, cogito@plaza.snu.ac.kr

Abstract

본 논문은 자바 언어가 가져올 수 있는 시큐리티 문제에 대해서 고찰하고 자바 실행 가능 웹브라우져(Java Enabled Web Browser이하 JEWB)에서의 보안 취약점들의 이용 가능성과 자바의 시큐리티 메커니즘들에 대해서 평가한다. 실행가능 내용(Excutable Content 이하 EC)에 대해서 우선 논의한 후에, 이 논문은 EC의 잠재적 취약성과 그에 대해 제안된 자바의 메커니즘에 대해서 그리고 마지막으로 이러한 메커니즘들의 효과에 대해 분석하고자 한다.
Keywords: Java , Security , WWW

Contents

1 소개(Introduction)

1.1 Excutable Content에 대한 고찰

2 문제점들

2.1 어떠한 것들이 제어되어야 하는가?

2.2 시나리오들

3 자바의 시큐리티 메커니즘

3.1 자바 언어에 대한 고찰

3.2 라이브러리들

ClassLoader

클래스파일 검사(Class File Verification)

클래스파일 포맷

바이트코드와 가상기계

검사 프로세스(The Verification Process)

바이트코드 검사기(The Bytecode Verifier)

3.3 Security Manager

3.4 Java Enabled Browser(자바 가능 브라우져)

4 분석

4.1 설계

4.2 구현

4.3 시나리오들

5 결론

[참고 문헌]

1. 소개(Introduction)

자바는 썬마이크로시스템 사에서 개발된 간결하고 객체지향적이고, 플랫폼에 무관한 실행이 보장되는 프로그래밍 언어이다. 이러한 특징 중 가장 중요한 것은 플랫폼에 무관한 실행 즉 포터블 하다는 것이다. 포터블하다는 것은 네트웍상에서 프로그램들 또한 동적으로 로드되고 로컬하게 실행된다는
것이다. 특히, 애플릿이라고 하는 작은 프로그램들이 로드되고 사용자의 웹브라우져에서 실행되는 동안 사용자는 웹을 "서핑"할 수 있다.(핫자바가 자바언어로 쓰여진 그러한 브라우져이고, 네스케이프 2.0은 그러한 자바애플릿을 지원한다.) 이러한 개념들이 매우 강력한 것은 틀림없지만, 새로운 보안 문제를 초래하는 것 또한 확실하다. 자바언어와 실행 시스템들은(여기에는 라이브러리, 컴파일러, 바이트코드 인터프리터등이 포함됨) 선사가 자바의 안전성을 주장했듯이 이러한 보안상의 문제들을 해결하기 위한 시도를 하고 있다.

1.1. Excutable Content에 대한 고찰

EC는 실행 가능한 코드를 데이타와 함께 보낼 수 있다는 개념이다. EC는 웹에 강력한 상호작용성을 부여할 수 있기 때문에 주목을 받고 있다. 지난 수년간 웹의 사용은 폭발적으로 증가했는데, 여기에는 웹에 기존의 응용프로그램을 웹에 맞게 수정하려는 시도 역시 증가해왔다. 폼과 스크립트를 통해서 많은 기능을 웹이 추가해 왔지만, 이러한 방법은 이미 한계를 보이고 있으며, 사용자가 로컬 호스트상에서 프로그래밍언어로 짜여진 프로그램을 웹 브라우져를 이용해 실행할 수 있게 될 경우 웹브라우져의 능력은 기존의 어플리케이션들과 필적하게 된다.

2. 문제점들

자바 시큐리티에 대한 논의에 앞서, EC에 의해 발생될 수 있는 문제점들에 대한 이해가 선행되어야만 한다. EC의 장점은 소프트웨어의 실행 능력과 종류의 다양성의 증가에서 비롯된다고 할 수 있다.
그러나,자바 애플릿의 증가된 실행 능력은 또한 잠재적인 시큐리티 문제의 소지를 안고 있다. 사용자가 웹을 항해하는 동안, 사용자가 애플릿이 자신들의 파일을 지우거나 그들의 사적인 정보를 네트워크를 통해 흘려보낼 가능성에 대한 불안감을 느낄 필요가 없어야 하는 것이다.
문제의 핵심은 컴퓨터상에서 프로그램의 실행시 호스트의 특정한 자원에 대한 접근을 프로그램이 해야만 한다는 데 있다. EC의 경우에 실행되고 있는 프로그램은 신뢰될 수 없다. 자바 코드를 다운로드해서 실행하는 웹브라우져가 신뢰할 수 없는 프로그램에 대해서 자원에 대한 접근을 제어하지 못한다면, 해커가 호스트를 침입한 것과 마찬가지로 시스템에 손상을 입힐 수 있는 것이다. 불행하게도, 자원에 대한 접근을 완전히 금지하는 것등의 단순한 솔루션은 존재하지 않는다. 이유는 프로그램이 자원에 대한 접근을 허용하는 첫번째 이유가 유용한 프로그램이 그러한 자원들에 대해서 반드시 접근해야 하기 때문이다. 예를 들면 에디터에서 파일저장 기능이 없다면 이는 유용한 프로그램이라고 할 수 없는 것이다. 그러므로, 유용하면서도 안전한 EC를 원한다면, 자원에 대한 접근은 매우 주의깊게 통제되어야만 한다. 이하에서는 우선 고려해야 할 자원에 대해서 설명하고 충분한 안전장치가 없을 경우 발생할 수 있는 몇 가지 가상적 시나리오에 대해서 고찰한다.

2.1.어떠한 것들이 제어되어야 하는가?

실행될 프로그램을 위한 안전한 환경의 중요한 부분은 자원을 구분하여 이러한 자원들에 대해 특정한 형태로 제한된 접근을 허용하는 것이다. 도표 1은 그러한 자원들의 부분적인 예를 보여주는데, 자원의 이용가능성에 의한 공격의 형태도 마찬가지로 분류하고 있다. 가능한 네 가지 공격의 종류는:

사용자나 호스트에 대한 정보의 은페

정당한 시도에 대해서 자원을 사용할 수 없게 하는 서비스 거부 공격

데이터의 파괴나 수정(다른 프로그램이나 파일 시스템에 의해 사용중인 데이터 포함)

사용자의 화면에 음란한 장면을 보여주는 것등의 불쾌감 유발 행위.

이 도표가 가능한 모든 공격을 망라한 것이 아니라는 것에 주의해야 한다. 이는 단지 주어진 자원에 대한 공격에 대해 예를 들고 있는 것에 불과하다. 예를 들면, 스푸핑프로그램은(사용자에게 실제와 다르게 보이는 프로그램) 원래의 프로그램과 같은 자원을 사용하는 것처럼 사용자를 속이기 위해 모든 자원을 공격을 위해 사용하고자 할 것이다.

자원 은폐 이용가능성 무결성 불쾌감 유발

파일 시스템 V V V V

네트워크 V

V

메모리 V V V V

출력 장치

V

입력 장치 V V
V

프로세스 제어
V
V

사용자 환경 V
V V

시스템 호출 V V V V

도표1. 호스트의 자원들

주어진 자원의 몇몇 요소들은 다른 것들에 비해 전체 접근을 해용하기 때문에 더욱 "위험"하다. 예를 들면 파일 시스템에 대해 알려지지 않은 프로그램이 전체적 접근을 허용하는 보안 정책을 유용하다고 판단할 수는 없다. 반대로, 대부분의 보안정책은 디스플레이 장치에 대해서는 전체적 접근을 허용하는것을 제한하지는 않는다.(물론, 다른 자원들에 대해서는 적절히 통제를 받는다는 가정하에서이다.)

도표1. 호스트의 자원들
자원	은폐	이용가능성	무결성	불쾌감 유발
파일 시스템	V	V	V	V
네트워크	V			V
메모리	V	V	V	V
출력 장치				V
입력 장치	V	V		V
프로세스 제어		V		V
사용자 환경	V		V	V
시스템 호출	V	V	V	V

2.2. 시나리오들

여기에서는 악의적인 프로그램이 수행할 수 있는 공격의 유형을 표시하는 몇가지 시나리오에 대한 예를 보이고자 한다. 공격의 분류는 이미 언급된 것과 마찬가지이다. 물론 가능한 모든 공격이 포함된 것은 아니고, 단지 발생할 수 있는 문제에 대한 감을 제시하기 위한 것이다.

무결성에 대한 공격

파일의 수정/삭제
사용중인 메모리의 내용에 대한 수정
프로세스나 스레드에 대한 종결

유용성 공격

과도한 메모리 할당
수천개의 윈도우 생성
우선순위가 높은 프로세스나 스레드 생성

은폐 공격

기계에 대한 정보 유출(etc/passwd 파일을 훔쳐가는 것)
네트워크를 통해 적이나 경쟁자에게나 개인이나 회사의 파일을 전송하는 행위

불쾌감 유발 공격

스크린에 음란한 그림을 표시하는 행위
컴퓨터를 통해 원하지 않는 음성을 들려주는 행위

3. 자바의 시큐리티 메커니즘

자바는 프로그래밍언어이다. 일단 자바가 웹과 무관한 어플리케이션으로 개발환경으로 쓰일 수도 있고 애플릿개발용으로도 쓰일 수 있다는 사실을 기억해야 한다. 그러므로 필자의 자바 시큐리티에 대한 논의는 실제로 EC에 대한 자바 언어의 사용에 대한 것이다.
EC(Excutable Content)를 제공하는 자바의 방식은 JEWB가 자바 인터프리터와 런타임 라이브러리를 보유하게 하는 것이다. 이러한 웹브라우져는 애플릿이라고 불리우는 자바 프로그램들을 다운로드할 수 있고 자바인터프리터가 이를 실행하게 만든다. 이러한 모델과 함께, 세가지 기본적언 계층이 존재하는데: 자바 언어, 표준 자바 라이브러리 그리고 웹브라우져이다. 시스템 전체의 시큐리티는 이러한 세 계층의 개개의 시큐리티에 기본적으로 의존하는 구조이다.

3.1. 자바 언어에 대한 고찰

자바는 C++과 비슷한 객체 지향 언어이다. 시큐리티 관점에서 본 중요한 언어적 특징은 변수와 메쏘드에 대해서 클래스 내부에서 접근 제어를 사용하는 것, 타입 정의들의 안전성, 언어의 데이터 형으로서 포인터의 부재, 가비지 콜렉션의 사용(자동적으로 메모리를 재분배), 분리된 네임스페이스의 사용등이다.
C++과 마찬가지로 자바는 객체들의 변수와 메쏘드에 대해서 접근을 제어할 능력을 가지고 있다. 이러한 접근 제어는 신용할 수 없는 코드에 대해 객채가 부적절하게 사용되지 않는다는 보장을 가능하게 한다. 예를 들면, 자바 라이브러리는 파일 객체에 대한 정의를 포함하는데, 파일 객체는 읽기용으로 public 메쏘드(누구나 호출 가능) 가지고 있고 또한 읽기용으로 저수준의 private 메쏘드(객체 메쏘드에 의해서만 호출가능한)를 가지고 있다. public 호출은 우선 시큐리티에 대한 체크를 수행하고 난 다음에 private 읽기를 호출한다. 자바는 신뢰되지 않은 코드가 파일 객체를 안전한게 조정하는 것을 public 메쏘드에 대한 접근만을 허용함으로써 보장하는 것이다. 그러므로, 접근제어능력은 프로그래머들이 라이브러리에 대한 접근제어를 정확히 명시함으로써 언어에 시큐리티가 보장된 라이브러리 작성을 가능하게 한다.
접근제어를 보장하는 다른 능력은 파이널(final)로서 클래스나 메쏘드를 선언하는 것이다. 이것은 악의적인 프로그래머가 핵심적인 라이브러리 클래스를 서브클래스로 사용하거나, 한 클래스의 메쏘드를 오버라이딩하는 것을 막아준다. 그러므로, 자바는 실제 메쏘드가 어떤 객체에 관계되었을때 객체의 컴파일시 타입에 맞게 쓰여진 파이널 메쏘드임을 보장한다. 이는 또한 객체의 행동의 특정한 부분이 수정되지 않았음을 보장하는 것이다.
자바는 또한 타입에 안전하게 설계되었다. 이것은 컴파일시 타입과 변수의 실행시 타입의 호환성이 보장됨을 의미한다. 이는 cast가 컴파일과 실행하는 경우에 그들이 유효한지를 확인하기 위해서 모두 체크됨을 의미한다. 이는 접근 제어를 비껴가기 위해서 객체에 대한 접근을 가장하는 것을 예방해 준다. 이미 보여진 File에 대한 예에서 보듯이, 이는 악의적인 코드가 File 객체에 대해 캐스팅을 하는 것에서 악의적인 코드의 MyFile 타입이 File타입과 동일한 형태를 지니지만 모든 메쏘드가 public인것을 막아준다.

3.2. 라이브러리들

스탠다드 자바 실행 환경은 다양한 유용한 라이브러리들로 가능해지는데, 이는 파일 시스템에 접근하거나, 네트워크에 접근하는것, 윈도우 툴킷이나 이외에 다양한 툴을 포함한다. 라이브러리의 정확한 분류는 매우 중요하다. 언어 자체는 안전한 라이브러리를 제공할 능력을 지니지만, 라이트러리 코드가 분류되지않고 정확히 쓰여지지 않을 경우 시스템이 안전할 수는 없다. 라이브러리가 자바 실행시의 2.1에서 언급한 시스템 자원에 대한 접근을 가능하게 하는 한 부분이기 때문에, 라이브러리의 정확한 구현은 핵심적인 중요성을 지닌다.
라이브러리의 접근 제한은 기본적으로 세가지 메커니즘에 의존한다. 첫번째는 자바 언어의 오브젝트 메쏘드와 시스템 자원에 대한 접근 제한을 공급하는 방식으로서 이루어지고 두번째는 특정한 ClassLoader가 특정한 코드를 로드하는 방식으로 이루어진다. 마지막 메커니즘은 글로벌 SecurityManager가 특정한 작용의 유용성을 검사하는 명백한 호출을 사용함으로써 이루어진다.
ClassLoader
자바 실행은 새로운 클래스를 로드하는데 명백한 두가지 방식을 가진다. 기본적인 방식은 로컬 호스트의 파일에서 클래스를 로드하는 것이다. 이 방식은 ClassLoader를 포함하지 않는다. 네트워크를 이용하는 등의 방식으로 클래스를 로딩하는 것은 관련된 ClassLoader를 요구한다. (예를 들면 특화된 방법을 지니는 ClassLoader 클래스의 서브타이프) ClassLoader는 클래스의 원시 데이터를 내부의 클래스를 대표하는 데이터 구조로 변환하는 역할을 한다.
자바 애플릿들이 가능한한 포터블하기 위해서, 자바 컴파일러는 머신 코드를 컴파일하지 않고 대신에 아키텍쳐에 무관한 가상 기계용 바이트 코드를 컴파일한다. 자바 인터프리터는 이러한 바이트코드를 인터프리트해서 프로그램을 실행한다. 그러므로, 애플릿은 소스코드나 머신 코드가 아니라 바이트코드 형태로 전달된다. 이것은 ClassLoader가 바이트코드만을 다룰 수 있음을 의미한다.
클래스파일 검사(Class File Verification)
컴파일러가 타입을 검사하지만 "위험한" 컴파일러를 사용함으로써 공격을 받을 수 있는 가능성이 여전히 있다. 핫자바(tm)브라우저와 같은 어플리케이션은 소스코드를 전송받은 후 컴파일을 하지 않는다; 이런 어플리케이션은 이미 컴파일된 클래스파일들을 전송받는다. 핫자바 브라우저는 그 바이트 코드가 믿을 만한 자바컴파일러에서 생성되었는지 또는 인터프리터를 공격하려는 적으로부터 생성되었는지 확인할 방법이 전혀 없다.
외부에서 유입된 모든 클래스파일들은 검사기에서 확인되어야 한다. 검사기는 그 클래스 파일이 올바른 포맷으로 이루어져 있는지 확인한다. 바이트코드에 대한 "구조적 제한"의 세트를 구성하는 간단한 논리 확인자를 사용함으로써 바이트코드를 검사할 수 있다.
바이트코드 검사기는 인터프리터의 퍼포먼스를 향상시키기도 한다. 각 인터프리트된 명령어에 대해서 수행되어야 했을 실행시간 확인을 하지 않아도 된다. 오히려 인터프리터는 이러한 확인이 이미 수행되었다고 간주할 수 있다. 각각에 대한 확인은 그다지 크게 부담되지 않을 수 있어도 각 바이트코드 명령어의 실행에 대한 몇가지 기계 명령어가 없어질 수 있다.
예를 들어 인터프리터는 코드가 다음 제한들을 가능한한 준수한다는 것을 고려해서 작동할 수 있게 된다.

스택 오버플로우나 언더플로우가 없다.
모든 레지스터 억세스와 저장이 가능하다.
모든 바이트코드 명령어에 대한 파라메터가 올바르다.
규칙에 어긋나는 데이타 변환이 없다.
검사기는 자바컴파일러와는 독립적이다. 현재의 컴파일러에 의해 생성되는 모든 코드를 체크하지만 검사기는 현재의 컴파일러가 생성할 수 없는 코드들도 확인한다. 구조적인 기준에 만족하는 바이트코드의 어떠한 조합이라도 검사기에 의해 확인될 것이다.
다른 언어들도 자바의 클래스포맷으로 컴파일될 수 있다. 바이트코드검사기는 자바언어에만 제한되지 않음으로써 사용자가 파이어월 건너에서 어떠한 코드도 안전하게 불러들일 수 있도록 해 준다.
클래스파일 포맷
각 자바 클래스파일은 분할된 상태로 네트워크를 통해 전송되어진다. 클래스파일은 간단히 보면 8비트 데이터의 흐름이다. 모든 16비트나 32비트의 값들은 각기 둘 혹은 넷의 8비트 바이트들로 변형된 상태로 읽혀진 후 마지막에 가서 하나의 전체로 합쳐진다.
기본 포맷
하나의 클래스파일은 다음을 포함한다:

매직 상수
메이저 버전 정보와 마이너 버전 정보
"상수 풀(contant pool)"
이 클래스에 대한 정보(이름, 수퍼클래스 등)
이 클래스의 각 필드와 메쏘드에 대한 정보
디버깅 정보
상수 풀은 여러가지 데이터의 상이한 조합이다. 상수풀의 각 데이터는 다음 중 하나가 될 수 있다:

유니코드 스트링
클래스나 인터페이스의 이름
필드나 메쏘드에 대한 레퍼런스
수치값
상수의 문자열값
클래스파일의 다른 어떤 부분도 스트링, 클래스, 필드 또는 메쏘드에 대한 레퍼런스를 만들어내지 않는다. 이러한 모든 레퍼런스는 상수풀의 인덱스들에 의해서 이루어진다.
클래스의 각 필드와 메쏘드에 대해서 클래스파일의 바이트는 필드나 메쏘드의 이름과 그 유형을 나타낸다. 필드나 메쏘드의 타입은 시그너처(signature)라고 불리는 스트링에 의해서 나타내어진다. 필드는 필드의 초기값을 알려주는 추가적인 속성을 가질 수 있다. 메쏘드는 그 메쏘드를 실행시킬 코드를 알려주는 추가적인 속성을 가질 수 있다.
실제로는 메쏘드가 중첩된 코드 속성을 가질 수 있다. 코드라는 속성은 인터프리터를 통해 실행될 바이트코드라는 것을 나타낸다. 메쏘드는 또한 그 메쏘드의 기계코드를 구현한 SPARC-CODE나 386-CODE와 같은 속성을 가질 수 있다. 핫자바 브라우저는 이 머신코드가 구조적으로 안전한 것인지 판별할 수 없기 때문에 신뢰할 수 없는 출처에서 나온 모든 메쏘드의 기계모드를 무시한다.
핫자바 브라우저에서는 현재 네트워크를 통해서 전송되는 어떠한 클래스파일도 신뢰할 수 없다고 간주한다. 핫자바 브라우저는 로컬 클래스 파일에서 불러들여진 기계코드만을 실행한다. 어쨌거나 클래스포맷은 작성자가 클래스파일에 전자 서명을 남길 수 있도록 한다. 앞으로의 브라우저들은 신뢰할 수 있는 출처에서 나온 전자 서명된 코드를 좀 더 신뢰하게 될 것이다.
바이트코드와 가상기계
코드 속성은 가상기계의 기계언어에서 메쏘드를 실행시키기 위한 정보를 제공한다. 각 메쏘드에 대한 정보는 다음을 포함한다:

메쏘드가 필요로 하는 최대 스택 크기
메쏘드가 사용하는 레지스터의 최대 수
메쏘드를 실행시키는 실제 코드.
이 바이트코드는 자바 가상기계를 위한 것이다.

예외 핸들러에 대한 테이블.
이 테이블의 각 값들은 바이트코드, 예외 유형 그리고 예외 핸들러에 대한 오프셋에 시작오프셋, 종료오프젯을 부여한다. 만일 표시된 유형의 예외가 시작오프셋과 종료오프셋에서 표시된 코드 안에서 발생한다면 그 예외에 대한 핸들러는 주어진 핸들러 오프셋에서 발견될 것이라는 것을 그 값이 의미한다.

자바 가상기계는 여섯가지의 원시 유형을 정의한다:

32비트 정수 ("integers")
64비트 정수 ("longs" 또는 "long integers")
32비트 실수 ("single floats")
64비트 실수 ("double floats")
객체와 배열에 대한 포인터 ("handles")
가상기계코드에 대한 포인터 ("return addresses")

자바 가상기계는 또한 몇가지의 배열 유형을 정의한다: 이 유형들은 integers, longs, single floats, double floats, handles, booleans, bytes (8-bit integers), shorts (16-bit integers) 그리고 Unicode 문자들의 배열을 포함한다. 핸들의 배열은 그 배열이 잡을 수 있는 객체의 클래스를 표시하는 추가적인 유형필드를 갖고 있다.
각 메쏘드 활성화는 구분된 Expression-Evaluation 스택과 로컬 레지스터의 세트를 갖고 있다. 각 레지스터와 각 스택 위치는 하나의 integer, single float, handle 또는 return address를 잡을 수 있어야 한다. longs와 double floats는 두 연속적인 스택 위치나 두 연속적인 레지스터에 맞아 들어야 한다. 가상기계 명령어들("opcodes")은 낮은 숫자가 매겨진 레지스터의 인덱스를 사용하면서 레지스터에서 longs와 double floats를 가리켜야 한다.
스택과 레지스터의 객체들은 (반드시) 태그된 것은 아니다. 가상기계 명령어 조합은 옵코드들이 다른 원시 데이타 유형에서 작동하도록 한다. 예를 들어 ineg, fneg, lneg 그리고 dneg의 각 negate는 그 스택의 가장 위쪽에 있는 아이템들이지만 각 스택의 가장 위쪽의 아이템이 각각 순서대로 integer, single float, long 또는 double float이라고 받아들인다.
바이트코드 명령어들은 몇가지 범주로 나뉠 수 있다:

스택에 상수들을 추가하기
레지스터의 값을 엑세스하거나 변경하기
배열을 억세스하기
스택 연산하기 (예를 들어 swap, dup, pop)
산수, 논리 그리고 변환 명령어들
제어 전송
함수 리턴
객체 필드 연산하기
메쏘드 주문
객체 생성
유형 불러들이기

각 바이트코드는 0 또는 추가적인 오퍼랜드 정보의 바이트가 뒤에 따라 오는 1바이트 옵코드로 이루어져 있다. 두 가지의 "테이블 검색" 명령어 에 대한 예외를 제외하고서는 모든 명령어들은 옵코드에 근거한 정해진 길이를 갖게 된다.
검사 프로세스(The Verification Process)
검사기는 4가지의 과정을 통해 작동한다.
과정 1
첫번째 과정은 가장 간단한 과정이다. 이 과정은 그 클래스가 인터프리터로 처음 읽혀졌을 때 일어난다.
이 과정은 클래스파일이 클래스파일의 포맷을 갖추고 있는지 확인한다. 첫번째 몇 바이트가 올바른 매직 넘버값을 갖고 있어야 한다. 모든 인식된 속성이 적절한 길이이어야 한다. 클래스파일은 잘려지거나 끝 부분에 추가적인 바이트가 있어서는 안 된다. 상수풀은 알아볼 수 없는 정보를 갖고 있어야 안 된다.
과정 2
두번째 과정에서는 검사기가 클래스파일의 포맷에 대해서 좀 더 깊이 검사를 해 본다. 검사기는 바이트코드를 검사하지 않고 수행할 수있는 모든 검사를 수행한다. 과정 2에서 찾아지는 에러들은 다음의 것들이다:

클래스 final이 서브클래스되지 않았는지 확인하고, 메쏘드 final이 덮어씌어지지 않았는지 확인한다.
클래스 Object 이 외의 모든 클래스가 수퍼클래스를 갖고 있는지 확인한다.
상수풀이 정해진 제한을 만족하는지 확인한다. 예를 들어 상수풀에서 클래스 레퍼런스는 상수풀의 유니코드 문자열 레퍼런스를 가리키는 필드를 반드시 갖고 있어야 한다.
상수풀의 모든 필드 레퍼런스와 메쏘드 메퍼런스가 규칙에 맞는 이름을 갖고 있는지, 규칙에 맞는 클래스를 갖고있는지, 그리고 규칙에 맞는 유형 시그너쳐를 갖고 있는지 확인한다.

필드와 메쏘드 레퍼런스들이 검사될 때에 이 과정은 주어진 필드와 메쏘드가 실제로 주어진 클래스에 존재하는지 확인하지 않는다는 것을 잊으면 안된다; 이 과정에서는 유형 시그너쳐가 실제 존재하는 클래스를 가리키는지 여부도 확인하지 않는다. 그보다는 그저 그 시그너쳐가 규칙에 맞는 시그너처로 "보여야" 하는 것이다. 좀 더 자세히 확인하는 것은 과정 3이나 4에서 이루어진다.
과정 3
이 과정은 클래스 검사에서 가장 복잡한 과정이다. 각 메쏘드에 대한 바이트코드들이 검사된다. 데이타흐름 분석이 각 메쏘드에 대해서 수행된다. 프로그램 상의 주어진 어떠한 위치에서, 그 지점으로 도달하기 위해 어떠한 코드경로가 잡혀지든 검사기는 항상 다음의 항목들을 확인한다:

스택은 항상 같은 크기이고, 같은 유형의 객체를 포함한다.
적절한 유형의 값을 갖고 있다는 것이 알려지지 않은 레지스터는 억세스 되지 않는다.
적절한 인수와 함께 메쏘드들은 호출된다.
필드들은 적절한 유형의 값들로 변경된다.
모든 옵코드들은 스택과 레지스터에 적절한 타입의 인수를 갖고 있다.

이 과정에 대한 좀 더 자세한 정보는 바이트코드 검사기(The Bytecode Verifier)섹션에 나와 있다.
과정 4
효율을 높이기 위해서 과정 3에서 수행될 수 있었던 몇가지 검사들이 실제로 그 코드가 실행될 때까지 미루어진다. 검사기의 과정 3은 그 클래스파일이 반드시 로딩되어야 될 때까지 클래스파일을 로딩하지 않는다.
예를 들어 만일 어느 메쏘드가 유형 foobarType의 객체를 돌려주는 또다른 메쏘드를 호출하고 그 객체가 같은 유형의 필드로 곧바로 할당된다면 검사기는 유형 foobarType이 존재하는지 확인하는 수고를 하지 않는다. 그러나 그 객체가 유형 anotherType의 필드로 할당된다면 foobarType가 anotherType의 서브클래스인지를 확인하기 위하여 foobarType와anotherType 둘 다의 정의(definition)가 로드되어야 한다.
어떤 클래스를 레퍼런스하는 명령어가 처음으로 실행되면 검사기는 다음의 것들을 한다:

그 클래스의 정의가 이미 로드되지 않았다면 그 정의를 로드한다.
현재 실행되는 클래스가 주어진 클래스를 러퍼런스하는 것이 허가되어있는지 확인한다.

명령어가 처음으로 메쏘드를 호출하거나 필드를 억세스하거나 변경하면 검사기는 다음의 것들을 한다:

주어진 클래스에서 그 메쏘드나 필드가 존재하는지 확인한다.
메쏘드가 필드가 표시된 시그너쳐를 갖고 있는지 확인한다.
현재 실행되고 있는 메쏘드가 주어진 메쏘드나 필드에 접근하는지 확인한다.

검사기의 이 과정은 스택 객체의 유형은 조사할 필요가 없다. 그 조사는 과정 3에서 이미 수행되었다.
조사가 수행된 이후에 바이트코드 스트림의 명령어는 다른 형태의 명령어로 대치된다. 예를 들어 옵코드 new는 new_quick로 대치된다. 이 또다른 형태의 명령어는 이 명령어에 대한 조사가 이미 수행되었고 다시 조사할 필요가 없다는 것을 나타낸다. 과정 3에서 이 _quick명령어가 나타나는 것은 잘못된 것이다.
바이트코드 검사기(The Bytecode Verifier)
위에서 나타난 바와 같이 바이트코드 검사기(bytecode verifier)의 과정 3은 클래스검사에서 가장 복잡한 과정이다.
첫째로, 가상기계 명령어를 이루고 있는 바이트들은 명령어의 나열로 쪼개어지고 각 명령어들에 대한 시작 오프셋은 비트테이블에 보관된다. 그 후에 검사기는 두번째로 바이트들로 들어가고 명령어들을 분산한다. 이 과정에서 명령어들은 구조로 바뀐다. 각 명령어들에 대해 인수가 존재한다면 그 인수들을 받아들일 수 있는지 확인한다.

모든 흐름제어 명령어들은 명령어의 시작부분으로 간다. 명령어의 중간으로 가지를 뻗는 것은 절대로 허락되지 않는다. 마찬가지로 코드의 시작부분전으로 가지를 뻗거나 끝부분 이후로 가지를 뻗는 것도 절대로 허락되지 않는다.
모든 레지스터 레퍼런스들은 규정된 레지스터이다. 코드는 그 메쏘드가 사용한다고 선언한 레지스터의 수보다 더 많이 레지스터를 억세스하거나 수정할 수 없다.
상수풀에 대한 모든 레퍼런스는 적절한 유형의 값이어야 한다. 예를들어 ldc1이라는 옵코드는 정수, 실수 그리고 String으로만 사용될 수 있다. 옵코드 getfield는 반드시 필드를 레퍼런스해야만 한다.
코드는 명령어의 중간에서 끝나지 않는다.
각 예외적인 핸들러에 대해서 시작하는 부분과 끝나는 부분은 명령어의 시작부분을 가리켜야만 한다. 예외적인 핸들러의 오프셋은 반드시 가능한 명령어야 한다. 시작 부분은 반드시 끝나는 부분보다 앞에 있어야 한다.

각 명령어에 대하여 검사기는 그 명령어를 실행시키기 전에 스택의 값과 레지스터의 값에 대해서 계속하여 추적을 한다. 각 스택에 대하여 검사기는 스택의 길이와 스택에 있는 각 원소들의 유형을 알아야 한다. 각 레지스터에 대하여 검사기는 레지스터의 값의 유형이나 레지스터가 잘못된 값을 갖고 있지는 않은지 알아야 한다. 스택의 값의 유형을 결정할 때에 여러가지 보통의 정수 유형(예를 들어 byte, short, char을 바이트코드 검사기가 구분할 필요는 없다.
다음으로 데이터흐름 분석기가 초기화되어진다. 첫번째 명령어에 대해서 더 낮은 번호가 매겨진 레지스터가 그 메쏘드의 유형 시그너처에서 나타난 유형을 저장한다;그 스택은 비어있다. 모든 다른 레지스터들은 잘못된 값을 갖고 있다. 모든 다른 명령어들에 대해서 그 명령어는 아직 검사되지 않았다고 표시한다; 명령어의 스택이나 레지스터에는 아직 아무런 정보도 없다.
마지막으로 데이터흐름 분석기가 실행된다. 각 명령어들에 대해서 그 명령어가 검사될 필요가 있는지 없는지를 알리는 "changed"라는 비트가 있다. 처음에는 이 "changed" 비트는 첫번째 명령어에만 켜져 있다. 데이터흐름 분석기는 다음의 루프를 실행한다:

그 "changed" 비트가 켜져 있는 가상 기계 명령어를 찾는다. 만일 "changed"비트가 켜져 있는 명령어가 하나도 없다면 그 메쏘드는 성공적으로 검사된 것이다. "changed"비트를 끈다.
그 스택과 레지스터에 대해서 이 명령어의 영향을 에뮬레이트한다:

명령어가 스택의 값을 사용한다면, 스택에 충분한 원소가 있는지, 스택의 가장 위의 원소(들)이 적절한 유형인지 확인한다. 그렇지 않다면 실패한다.
명령어가 레지스터를 사용한다면, 선택된 레지스터가 적절한 유형의 값을 갖고 있는지 확인한다. 그렇지 않다면 실패한다.
명령어가 스택에 값을 추가한다면, 그 알려진 유형을 스택의 가장 처음 부분에 추가한다. 스택에 새로운 원소을 위한 충분한 공간이 있는지 확인한다.
명령어가 레지스터를 변경한다면 그 레지스터는 새로운 유형을 갖는다고 표시한다.

이 명령어를 뒤따르는 가상 기계의 명령어들을 결정한다. 뒤따르는 명령어들은 다음 중 한 가지이다:

현재의 명령어가 조건없는 goto, return 또는 throw goto, return또는 throw가 아니라면 그 다음 명령어이다. 만일 마지막 명령어를 "fall off"하게 된다면 끝낸다.
조건이 있는 또는 조건이 없는 가지의 끝.
이 명령어에 대한 모든 예외 핸들러.

현재 명령어의 마지막에 있는 스택과 레지스터의 상태를 각 뒤따르는 명령어들에게 합친다. 예외핸들러의 경우(2c)에는 예외핸들러 정보에 나타나 있는 예외 유형의 하나의 객체를 갖도록 스택을 변경한다.

만일 이번이 뒤따르는 명령어를 첫번째로 검사하는 것이라면 2번째 과정과 3번째 과정에서 계산된 스택과 레지스터의 갑이 뒤따르는 명령어를 실행하기 이전에 스택과 레지스터의 상태라는 것을 표시한다; 뒤따르는 명령어의 "changed"비트를 켠다.
그 명령어가 이전에 검사되었다면, 2번째 과정과 3번째 과정에서 계산된 스택과 레지스터의 값을 이미 그 곳에 있던 값으로 전송한다; 만일 어떤 변경이 있었다면 "changed"비트를 켠다.

첫번째 과정으로 간다.
두 스택을 합치려면 각 스택의 원소의 수가 똑같아야 한다. 만일 같지 않다면 실패가 표시된다. 두 스택의 대칭되는 장소에 서로 다른 유형의 핸들이 나타나지 않는다면 두 스택은 똑같아야 한다. 이런 경우에 머지된 스택은 두 핸들 유형의 공통 조상을 갖게 된다.
두 레지스터 상태를 합치려면 두 레지스터를 비교한다. 두 유형이 똑같지 않고 각각이 핸들을 갖고 있지 않다면 레지스터가 미지의(그리고 사용할 수 없는) 값을 갖고 있다고 표시한다. 핸들 유형을 구분하기 위해서 머지된 상태는 두 유형의 공통 조상을 갖게 된다.
만일 데이터흐름 분석기가 어떤 실패를 보고하지 않고 메쏘드에서 실행된다면 그 메쏘드는 클래스파일 분석기의 과정 3에 의해 성공적으로 검사된 것이다.
바이트코드의 적합성을 체크하는 것과 함께, ClassLoader는 다운로드된 코드의 네임스페이스를 생성하는 역할을 한다.

3.3. Security Manager

현재의 자바 버젼에서는, SecurityManager는 상세히 언급되어 있지 않다. 그럼에도, 자바 베타 버젼과 함께 배포된 검사코드에서 그리고 어떠한 문서가 존재하는지 읽음으로서, SecurityManager의 개발 목적에 대해서 추론할 수 있다. SecurityManager는 특정한 종류의 행동을 검사하기 위해 호출되도록 설계된 다수의 메쏘드를 포함한다. SecurityManager 클래쓰는 직접적으로 사용되지 않는다. (각각의 체크는 보안상의 예외를 검사하는 것을 기본으로 한다.), 대신에 서브클래스가 되고 시스템 SecurityManager로서 설치되도록 되어 있다. 서브클래스가 된 SecurityManager는 지정된 시큐리티 정책을 실행하는데 사용될 수 있다.
SecurityManager는 조건에 맞게 자원에 접근을 허용하는데 극도로 유연하고 강력한 방식을 보장해 주고 있다. 접근을 체크하는 SecurityManager의 메쏘드는 조건적 접근 제어 정책을 구현하는데 필요한 인자들로 넘겨지는데, 이는 코드의 출처(로컬이나 네트워크) 결정하는 실행 스택을 체크하는 능력을 가지는 것과 마찬가지이다.
잠재적으로 위험한 시스템 자원을 생성할 가능성이 있는 라이브러리 코드에 대한 표준적인 접근 방식은 위험하지 않은 연산들에 대해서만 접근을 허용하고 제한된 기반에서만 접근가능한 시스템 호출에 대해 시큐리티 검사를 수행하는 것이다.(SecurityManager를 사용)
public boolean mkdir(String path) throws IOException    {

    SecurityManager security = System.getSecurityManager();

    if (security != null) {

               security.checkWrite(path);

    }

    return mkdir0();
}
시큐리티 체크의 예시. 이 예는 기본적인 접근 방식을 보여준다: public 메쏘드 mkdir은 시스템SecurityManager를 체크(체크가 통과되지 않을 때는 예외를 생성하는)하고 다음에 저수준의 private 메쏘드인 mkdir0을 호출한다.

3.4. Java Enabled Browser(자바 가능 브라우져)

웹 브라우져 또한 시스템의 보안에 있어서 중요한 역할을 한다. 웹 브라우져는 다운로드된 자바 코드를 실행하는 보안 정책을 정의하고 구현한다. JEWB는 자바 인터프리터와 실행 시간 라이브러리와 SecurityManager 및 다양한 ClassLoader를 포함할 것이다. 시큐리티 관점에서 본다면, SecurityManager의 웹 브라우져상의 구현이 ClassLoader의 구현보다 더욱 중요하다.
SecurityManager는 핵심적인 시스템 자원에 대한 접근을 통제한다. 이것은 JEWB의 구현자가 SecurityManager를 서브클래싱하고 특정한 메쏘드를 오버라이딩하거나 새로운 버젼을 시스템SecurityManager로써 설치하는 것에 의해 특정한 보안 정책을 구현하는 것을 가능하게 해준다. 서브클래스된 SecurityManager는 보안 정책을 구현하기 때문에, 웹브라우져의 SecurityManager의 버젼이 정확히 구현된 것이 매우 중요하게 된다. 극단적으로, JEWB가 시스템 SecurityManager를 설치하지 않았을 경우에는, 애플릿은 로컬 자바 에플리케이션과 같은 접근 권한을 가지게 될 것이다.
웹 브라우져의 시큐리티 정책은 SecurityManager의 수단들이 매우 유연한 인터페이스를 제공하기 때문에 임의적으로 복잡해질 수 있다. 프로그램될 수 있다면 어떠한 시큐리티 정책도 사용될 수 있는 것이다. 예를 들어, 시큐리티 정책은 SecurityManager가 어떤 사용자가 어떤 접근을 시도했는지에 대해서도 조사할 수 있게 한다.

4.분석

자바가 제공하는 executable content에 대한 보안 모델에 대한 분석은 두 단락으로 행해질 것이다. 첫번째 단락에서는, 자바의 고수준 설계가 논의될 것이다. 두번째 단락에서는, 구현의 보다 특정한 부분의 유용성에 대해서 논의될 것이다.

4.1. 설계

자바의 보안 모델은 거의 전적으로 다운로드된 바이트코드를 검사하는 능력에 의존한다, 그 능력은 의도되지 않은 자원에 대한 접근을 금지할 수 있도록 분류하고 라이브러리를 쓸 수 있는 것을 의미한다. 또한, 웹 브라우져의 개발자들이 우수한 보안 정책을 구현하고 코드를 쓸 수 있는 것을 의미한다.

왜 바이트코드인가?

자바 프로그램을 컴파일된 바이트코드 형태로 변환하기로 한 결정은 시큐리티 측면에서는 의문을 불러일으키는 사항이다. 시스템은 자바 소스코드가 바이트 코드 대신에 쓰일 수 있다면 더욱 안전할 것이다. 바이트코드의 사용은 바이트코드의 검증 과정을 필요로 한다. 만일 자바소스코드가 쓰였다면, 코드의 안전성은 소스를 직접적으로 인터프리팅하거나 자바코드를 로컬 상에서 신뢰할 수 있는 컴파일러를 사용함으로써 보장될 수 있었을 것이다. 이것은 시큐리티에 대한 단순한 접근일 수 있는데 이는 자바 컴파일러는 이미 신뢰할 수 있기 때문이다.(자바 실행 시스템은 로컬 바이트코드에 대해서는 검사를 수행하지 않는다.) 다른 언어로 된 프로그램(바이트코드)이 호환성이 있는가에 대한 체크를 수행하는 프로그램에 대한 첨가는 시스템에 또다른 실패의 가능성을 더한다.

물론 바이트 코드를 사용하는데는 많은 이유가 있다. 우선, 그것은 확실한 추상화를 보장하는데 이는 자바 프로그램에 대한 역분해 공학을 예방한다. 이것이 사실이긴 하지만, 바이트코드가 역컴파일하는 것이 불가능한 것은 아니다. 그리고 소스 코드를 직접 다루는다른 코드 추상화 기술들이 존재한다. 다음으로, 바이트코드의 표현은 크기가 줄어들게 한다. 현재로는 이것이 사실은 아니다. 현재의 모든 예에서, HotJava브라우져의 소스코드를 포함해서, 소스와 바이트코드는 거의 크기에 있어서 일치한다. 세번째로, 바이트코드 검사 과정은 컴파일 과정보다 빠를 수 있다. 그러므로 프로그램을 다운로딩하고 실행하는데 계산상 많은 시스템 자원을 사용할 필요가 없고 낮은 latency를 제공한다. 이러한 논의는 공평하게 강요적인데, 자바팀이 계산에 많이 의존하는 프로그램에 대해서는 "Just in Time"컴파일러를 사용할 수도 있다고 암시한 바가 있지만, 컴파일이 예방적이지 않음을 의미한다. 마지막 논의는 바이트 코드 검사기가 전형적인 컴파일러보다 덜 복 잡한 프로그램이어서, 정확성의 검사가 단순한 과정이라는 것이다. 사실 컴파일러는 모든 바이트코드가 신뢰성 있는 바이트코드 검사기로 검사될 수 있기 때문에 신뢰성을 가질 필요가 없다.(로컬 코드는 효율성을 이유로 해서 컴파일 시에 단 한번만 검사될 수 있다.)

보안성있는 라이브러리를 작성하는 것

우수한 라이브러리를 작성하고 검증하는 과정은 자바의 시큐리티에 있어 가장 중요하다고 하는데에는 이견이 있을 수 없다. Drew Dean과 Dan Wallach가 쓴 Security Flow in the HotJava Web Browser라는 논문에는 핫자바가 라이브러리 구현상의 에러로 인해 붕괴될 수 있는 좋은 예들을 보여주고 있다. Dean과 Wallach는 핫자바 1.0 alpha3 라이브러리의 구현상의 약점을 지니고 있음을 지적한다. 그들은 많은 수의 변수와 메쏘드가 퍼블릭으로 접근 가능하며, 시큐리티 체크를 하지 않아서, 시큐리티의 구멍을 허용하는 것을 증명했다. 이러한 종류의 문제들이 자바의 베타 버젼 라이브러리들에서는 해결이 이루어졌지만, 그러한 에러들은 정확한 검증이 단순한 작업이 아님을 보여주는 것이다.

시큐리티 문제는 라이브러리가 적절히 작성되었다고 해도 자바가 가능한 웹브라우져의 프로그래머가 정확히 SecurityManager에서 그들을 정확히 구현하고 명시해야 한다는 사실 때문에 더욱 어려워진다. SecurityManager는 기존의 더욱 확대된 메커니즘들에 비해서 유연한 시큐리티 정책을 수립하는데 특정하며 캡슐화된 방법을 가능하게 한다는 점에 있어 분명한 발전이다. 그럼에도 자바 시스템의 시큐리티에 대해 윕 브라우져가 직접적인 조작을 할 수 있는 사실은 명세와 구현에 있어 에러의 확률을 증가시킨다. 자바 자체는 매우 엄격한 검사를 수행하지만, 자바 가능한 브라우져가 자바의 내장 시큐리티에 의존하면서 그다지 엄격하지 않을 수 있는 것은 분명하다.

그러므로 자바의 시큐리티는 상당히 큰 코드들의 정확한 구현에 의존한다. 이러한 상황은 자바의 설계가 매우 유연한 시큐리티 모델을 제공하고자 한 결과이다. 프로그래머에게 시스템 시큐리티에 대한 조작을 가능하게 함으로써, 자바 제작자들은 잠재적인 보안의 취약성을 노출하지만 유연함을 제공했다.

4.2구현

자바 시큐리티의 유효성을 검사하기 위해서는 언급된 각각의 자원들에 대해서 제어하는 적절한 방법이 있는가에 대한 검사를 하는 것이 필요하다.

파일 시스템 - 특정한 SecurityManager가 주어진 파일에 대해 읽고 쓰기를 수행하는데 대해 체크하는 방식으로 파일 시스템에 대한 접근은 잘 보호되어 있다. 이는 접근 제어 목록이 매우 쉽게 구현할 수 있는 등의 유연한 정책을 가능하게 한다.
네트워크 - 네트워크에 대한 접근은 잘 보호되어 있다. SecurityManager가 소켓을 생성하거나 받아들이는데에 필요한 메쏘드에 대한 체크가 다른 네트워크 관련 메쏘드에 대한 호출의 보호와 함께 이루어진다. 마찬가지로 이러한 메쏘드들은 접근 제어를 허용하는 유연성을 가진다.
랜덤 메모리 - 메모리에 대한 보호는 언어 명세에 의해 기본적으로 이루어진다. 이미 할당된 메모리에 대한 접근에 대해 보호 작용이 존재하지만, 애플릿이 객체를 생성함으로써 현재의 이용 가능한 메모리를 할당하는 데에 대한 보호 작용은 존재하지 않는다.
출력 장치 - 출력 장치에 대한 보호 작용은 어떤 애플릿 윈도우도 안전하지 않음을 표시하는 특별한 마크를 의무적으로 표시하게 하는 한 방식이 존재한다. 또한, 애플릿은 장치에 대해 직접 접근할 수가 없으며, 대신에 자바 라이브러리에 의해 주어지는 방법을 사용해야만 한다.
입력 장치 - 애플릿은 애플릿의 윈도우가 선택되었을 경우에 키보드 입력이나 마우스 클릭에 대해서만 접근할 수 있다. 현재 다른 입력 장치는 지원되지 않는데, 카미라나 마이크로폰 같은 장치를 시큐리티 체크를 거치는 자바라이브러리를 통해 접근할 수 있는 가능성을 배제할 필요는 없다. 현재는 입력에 대한 특별한 시큐리티 체크는 존재하지 않는다.
프로세스 제어 - 쓰레드 제어에 대한 접근은 매우 제한적이다. 쓰레드와 쓰레드 그룹에 대한 접근을 체크하는 SecurityManager가 존재한다. 또한, 쓰레드의 priority에 대해서는 애플릿의 쓰레드가 지배적이지 않음을 확인가능하도록 설정될 수 있다.
사용자 환경 - 환경 변수에 대한 접근은 SecurityManager의 체크에 의해 보호된다. 자바 환경에 대한 부가적인 접근 제어는 클래스에 대한 언어의 접근 제어 메커니즘에 의해 제공된다.
시스템 호출 - SecurityManager는 어떠한 시스템 호출에 대해서도 체크하는데 이는 exit에 대한 요청도 포함한다.