달봉이 공부방

Vista는 보안을 위해서 새로운 보안 모델을 내놨고 따라서 이전 Windows에서는 관리자 계정으로 로그온만 하면 잘 실행되던 프로그램이 이제는 관리자로 로그온하더라도 권한 부족으로 실행에 실패할 상황에 처하게 되었다. 따라서 Vista는 실행 권한이라는 측면에서 이전 프로그램과의 호환성을 해결할 필요가 있게 되었다. 앞 포스트에서는 개발자가 UAC의 토큰 판단에 영향을 미칠 수 있는 방법에 대해서 알아봤다. 개발자에게는 그것이 중요한 내용이라 본다. 이제 이 포스트에서는  UAC가 권한 상승을 스스로 판단하는 기능 그리고 어떻게 레거시 프로그램들과의 호환성을 지원하고 있는지에 대해서 알아보겠다. 여기서 다룰 것은 다음 3가지를 포함한다.

▶Vista의 인스톨러를 자동 인식하는 기능

▶PCA(Program Compatibility Assistant)

▶Application Compatibility DataBase

■ 인스톨러를 인식할 수 있는 Vista

대부분의 인스톨러 프로그램은 관리자 권한이 필요하다. 인스톨러들은 Program Files 또는 HKEY_LOCAL_MACHINE\SOFTWARE 또는 HKEY_LOCAL_MACHINE\SERVICES에 또는 Windows\System32에 뭔가를 쓰려고 한다. 그러나 일반 사용자들은 이곳에 접근해서 쓸 수 있는 권한이 없다. 그래서 이런 작업을 필요하는 프로그램을 그냥 아무 생각없이 실행시켰다가 실패하도록 놔 두는 것보다는 UAC는 다른 어플리케이션을 인스톨시키는 작업을 하려는 어플리케이션을 실행시키려고 하는 때를 추측해서 잡아내서 사용자에게 권한 상승을 동의하겠냐고 묻도록 만들어졌다.

근데, 인스톨러를 감지해내는 근거가 어떤 수학적인 계산 근거가 아닌 경험적인 근거를 바탕으로 하고 있다. 그 근거나 "추측(guess)"이라는 것이다( 컴퓨터 업계에서 "추측"이 근거가 되다니 !  그러나 그렇다.) 그 추측은 2가지를 통해서 이뤄진다. 하나는 인스톨러 프로그램의 실행(EXE) 파일의 이름이 "setup", "install", 또는 "update" 같은 단어를 포함하고 있으면 UAC는 동의 확인 창을 띄운다. 만약 누군가 "setup.exe"를 "apple.exe"로 변경해서 실행시킨다면 물론 권한 상승용 동의 확인 창이 뜨지 않을 것이다. 그러나 Program Files, System32 또는 레지스트리에 뭔가를 쓰려고 하면에러가 발생할 것이다. 다른 하나는, 인스톨 프로그램을 만드는 프로그램으로 가장 널리 알려진 Wise 또는 Installshield 인스톨러로 만들어진 프로그램으로 인식하게 되면(이런 상용 프로그램을 만들어진 인스톨 프로그램은 인식하기가 매우 쉽다고 한다.) UAC는 동의 확인 창을 띄우게 된다.

■ PCA(Program Compatibility Assistant)

이 기능은 인스톨 프로그램을 스스로 인식할 수 있는 기능이 "추측"을 근거로 하는 것이라면 이 방법은 그 추측 결과들을 기반으로 해서 좀더 "합리적"인 Vista의 지원이다(그런가...달봉이한테는 그런 것 같다).  Vista는 단순히 인스톨 프로그램을 실행시킬뿐만 아니라 나름대로의 진보된 추측을 하게 된다. 인스톨 프로그램이라면 그 프로그램이 어떤 것을 인스톨했는가에 대한 기록을 남겨야 한다. 그래서 나중에 제어판의 "프로그램 추가/제거"를 통해서 어떤 프로그램이 인스톨되었는가에 대한 기록을 볼 수 있게 되는 것이고 그리고 다시 그것을 어떻게 제거할 것인가를 알 수도 있게 되는 것이다. Vista는 어떤 인스톨 프로그램이 잘 실행이 되지 않았다고 추측을 하게 되면 "Program Compatibility Assistant"라 불리는 대화창을 띄운다.

[그림] Program Compatibility Assistant

이 대화창은 사용자에게 이런 표현을 하고 있는 것이다:"내가 보기에는 뭔가 의심스러운데 제대로 설치된 것 맞니? 원한다면 내가 권장하는 다른 방법으로 다시 설치해보지 않을래?" 사용자가 다시 설치하겠다고 허락을 하게 되면 어떤 일이 일어나는 것일까. Vista가 무슨 일을 하는지를 알아보려면 이전에 보았던 "호환성"탭을 보면 된다.

[그림] 호환성 탭의 내용

이 호환성을 탭을 사용하면 이전 Windows 프로그램들의 많은 일반적인 문제들을 손쉽게 빨리 해결할 수 있다. 예를 들어 어떤 프로그램은 Windows 95, XP SP2처럼 특정 OS와 관련된 정보를 하드 코딩했을 수 있다. 만약 그런 경우라면 "이 프로그램은 Windows 95에 맞게 실행시켜라"라는 선택을 함으로써 Vista에서도 실행될 수 있도록 할 수 있다. 또한 Vista의 데스크톱에게 스크린의 해상도와 관련된 내용들을 이전 프로그램에 맞도록 지정해 줄 수도 있다.

프로그램을 인스톨하다가 실패하면 PCA는 호환성 탭에 설정된 내용에 대해서 약간 똑똑한 추측을 하게 되는 것이다. 즉 PCA 대화창은 "내가 생각하기에는 이런 설정으로 인스톨을 하면 될 것 같은데, 어떻게 함 다시 해 보시것습니까~~"라고 묻는 것이다.

이 대화창에서 설정된 내용은 레지스트리에 저장되도록 설계되어있다. 그래서 해당 프로그램을 실행시킬때마다 묻지 않는다. 다음 키에 프로그램 목록을 저장한다.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlas\Comptability Assistant\Persist

이 키 하위에 REG_DWORD타입의 엔트리를 만들고 EXE 실행 파일에 대한 풀 경로를 그 엔트리 이름으로 한다. 만약 호환성 탭에서 선택한 옵션들이 있다면 다음 키에 저장된다.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlas\Layers

호환성 탭에는 "관리자 권한으로 이 프로그램 실행"이라는 체크 박스도 있는데 이것을 체크해 두면 다음 실행부터는 권한 상승 동의 확인창이 뜨게 된다. 호환성 탭을 통한 권한 수준 설정은 해당 프로그램 복사본에만 해당한다. 즉 그 프로그램을 다른 폴더로 복사해서 다른 설정을 할 수도 있다는 것이다. 메너페스트 파일을 프로그램에 추가하게 되면 그 프로그램이 어떤 위치에 있던 상관없이 그 권한 수준 설정이 적용되는 것과는 대조적이다.

■Application Compatibility Toolkit "Shim"

앞에서 본 PCS기능은 기본적으로 지금 설명할 Application Compatibility Toolkit의 라이트 버전이라고 볼 수 있다. Vista에는 "shim"이라는 것이 있는데 이것은 프로세스의 권한 상승을 요청하는 Vista의 마지막 요소이다.  "shim"은 Application Compatibility Toolkit라 불리는 것이 생성하게 된다. 앞에서 알아본 PCA는 Vista와 호환성의 문제를 갖는 프로그램들의 EXE 파일들에 대해서, 어떤 특정 환경에서 대화창을 띄워서 호환성 탭의 설정 내용을 수정하도록 하기 위해서 몇가지 규칙을 따른다. 현재 버전의 프로그램이 불편은 하지만 그렇다고 업그레이드하고 싶지는 않고 그래서 약간의 설정만으로도 내 필요에는 충분한 경우 PCA를 사용하는 것은 괜찮은 일이다. 그러나 호환성을 위해서 설정을 배포해야 하는 컴퓨터들이 수백, 수천대에 달하고 또한 호환성 탭에서 제공하는 옵션들보다 훨씬 많은 내용의 설정들을 적용할 필요가 있다면 어떻게 해야 하나.

이때 필요한 것이 ACT(Application Compatibility Toolkit)이다. ACT는 "온라인 상의 해결 프로그램들(online fixes)"을 호환성의 문제를 가지고 있는 프로그램들에 적용해서 Vista와 이전의 프로그램들을 모두 만족하도록 하는 일련의 프로그램들을 말한다. "온라인상의 해결 프로그램"을 공식적으로는 "shim"이라고 부른다.

shim이라는 용어는 Application Compatibility Toolkit에서만 사용되는 용어는 아니다. 여러 버전의 CLR이 설치되어 있는 경우에 어떤 프로그램이 제작된 버전을 선택하는 경우에도 이런 shim 프로그램이 작동을 하는데 이것에 대해서는 로딩되는 CLR 버전 경정하기라는 이전 포스트에서 언급했다.

ACT의 shim은 호환성이 필요한 해당 프로그램을 위한 shim을 직접 제작해서 그룹 정책으로 중앙에서 배포한다는 점에서 호환성 탭의 shim과 다르다고 볼 수 있다. 또한 호환성 탭은 몇가지의 가능한 문제점들에 대한 해결책 옵션만을 가지고 있지만 ACT는 그 보다 훨씬 많은 문제점들에 대한 해결책을 가지고 있다.

ACT는 해결책들에 대한 데이터베이스 파일을 가지고 있는데, 그 확장자가 .SDB("System DataBase")로 되어 있는 파일들이다.  예를 들면 Vista와 함께 배포되는 sysmain.sdb이 있는데 기본적으로 \Windows\AppPatch 폴더 아래에 놓이게 된다. 그러나 그 데이터베이스 파일을 볼 수 있는 방법은 없다. 이 데이터베이스 파일에는 어디서 듣도 보지도 못한 수많은 프로그램들이 들어 있다. 따라서 sysmain.sdb가 UAC에게 어떤 프로그램의 경우에 권한 상승을 요청하는지에 대해서 이야기한다는 것은 무의미할 것이라고 본다. 여기서는 ACT라는 기능의 프로그램이 있다는 것을 이해하는 것으로서 마치도록 한다.

■ 연재를 마치면서

지금까지 UAC의 권한 상승이 일어나는 경우와 그 메커니즘들을 알아보았다. 여기까지 해서 개발자로서 필요한 UAC에 대한 개념은 어느 정도 살펴보았다고 생각한다. 그러나 UAC와 관련해서 커스터마이징을 할 수 있는 여러 내용들이 있다는 것을 알게 되었다. 필요하다면 뒤에 올 포스트에서는 이런 설정들에 대한 내용을 올려 보려 한다.

프로그램이 실행되는 도중에 권한 부족으로 프로그램이 중단되었다는 메세지는 신뢰도에 치명적이지 않을 수 없을 것이다. 그렇다면 프로그램이 시작되기 전에 관리자 권한이 필요하다는 것을 어떻게 UAC에게 알릴 것인가에 대한 것이 달봉이가 이전 포스트에서부터 기록하고 싶은 주제중의 하나이다. 그렇다고 동의 확인 창 또는 관리자 계정 요청 창이 뜨게 하지 않을 수는 없다. 관리자 권한이 필요하다면 사용자로부터의 확인을 요하는 창은 뜨게 되어 있다. 결국 개발자는 어떻게 하면 이 확인창을 뜨게 할 것인가를 고민해야 하는 것이 이 포스트들의 주요 내용이라고 할 수 있다.

앞 포스트에서는 사용자가 직접 Vista(UAC)에게 관리자 토큰을 사용하도록 하는 하는 방법에 대해서 알아봤다. 이번 포스트에서는 프로그램을 실행시킬때 UAC가 관리자 권한의 토큰이 필요하다는 것을 스스로 인식할 수 있는 방법에 대해서 알아본다. 관리자 권한이 필요하다는 것을 감지하게 되면 자동으로 권한 상승이 필요하게 되어서 사용자가 프로그램을 오른쪽 클릭해서 "관리자 권한으로 실행"을 선택하지 않더라도 동의 확인(Consent UI) 프롬프트를 보여주게 된다. 이렇게 할 수 있는 방법으로는 다음과 같은 4가지 경우가 있겠다.

▶ 개발자가 직접 실행 프로그램 EXE의 메너페스트 파일에 애플리케이션의 권한 상승이 필요하다는 사실을 표시해서 Vista에게 알려줄 수 있는 방법이 있다. 메너페스트 파일은 프로그램에 임베딩될 수도 있다.

▶ 만약 실행되는 프로그램이 어플리케이션 인스톨러라고 추측을 하게 되면 Vista는 권한 상승을 수행하게 된다. 보통 인스톨러는 보호를 받는 레지스트리나 디스크에 접근해서 쓰는 작업을 하기 때문이다.

▶ Vista의 윈도우 탐색기 또는 IE에는 PCA(Program Compatibility Assistant)라 불리는 것이 있다. 이것은 Vista이전의 프로그램을 실행하려고 하면 호환성 문제를 조사한다. 만약 그런게 발견되면 사용자에게 권한 상승이 필요한 프로그램이라는 마크를 달아둘 것인지를 묻는다. 사용자가 승인을 하게 되면 Vista이전의 그 프로그램은 권한 상승이 필요하다는 것을 레지스트리에 저장한다. 그때부터 이제 사용자가 그 프로그램을 실행시킬때마다 동의 확인 프롬프트창이 뜨게 된다.

▶ Vista에는 Application Compatibility Database라는 것을 가지고 있는데, 이것에는 권한 상승이 일어나지 않으면 실패하게 되는 과거의 프로그램들에 대한 목록이 들어 있다. 만약 사용자가 그런 프로그램들중의 하나를 실행시키면 UAC는 자동으로 동의 확인창을 띄우게 된다.

이중에서도 처음 1가지가 개발자와 직접적으로 관련된 것이고 나머지 3가지는 Vista에 내재되어 있는 자동 감식 기능이다.  이번 포스트에서는 첫번째에 대한 이야기를 정리하고 뒤의 3가지에 대해서는 다음 포스트에서 알아보도록 하겠다.

■ 권한 설정 내용을 포함하는 메너페스트를 인식할 수 있는 Vista

.NET를 공부하면서 이미 메너페스트라는 말을 많이 들어본 개발자들도 많이 있을 것이다. 어셈블리 메너페스트 그리고 ClickOnce에서는 어플리케이션 메너페스트, 배포 메너페스트등. 메너페스트라는 것은 OS에게 어플리케이션을 로딩하고 실행시키는 것에 대한 여러 정보를 알려 줄 수 있는 어플리케이션과 관련된 작은 텍스트 파일을 말한다. 그것들은 실행파일(어셈블리)에 임베딩될 수도 있고 또는 실행 파일의 외부에 별도의 파일로 존재할 수도 있어서 노트패드같은 편집기로 편집을 할 수도 있다. 메너페스트에는 많은 정보들이 있을 수 있지만 ▷해당 어플리케이션은 어떤 버전의 DLL을 필요로 하는가 ▷어플리케이션은 어떤 토큰을 필요로 하는가(일반 사용자 토큰 또는 관리자 권한 토큰)같은 사실들을 OS에 알려줄 수 있다.

원래 메너페스트는 XP에서 나타났는데, "Windows Side by Side"라는 것을 소개하면서 처음으로 메너페스트를 중요하게 사용하게 되었다. MSDN의 내용을 그대로 옮기면 다음과 같다. "Side-by-side 실행은 동일한 컴퓨터에서 여러 버전의 응용 프로그램 또는 구성 요소를 실행하는 기능입니다. 동일한 컴퓨터에서 여러 버전의 공용 언어 런타임과, 하나의 런타임 버전을 사용하는 여러 버전의 응용 프로그램 및 구성 요소를 동시에 사용할 수 있습니다" Side by Side라는 것은 이전 OS에서의 "DLL hell" 문제를 해결할 수 있는 훌륭한 방안으로 소개되었다. 버전이 다른 DLL을 함께 가지고 있어서 어플리케이션이 원하는 DLL을 사용하게 되면 문제를 해결할 수 있게 되는 것이다. 메너페스트를 OS에게 원하는  DLL의 버전을 알려줄 수 있는 수단으로 사용할 수 있는 것이다.

Vista에서도 메너페스트 파일을 관리하는 것은 여전히 Windows Side by Side에서 담당한다. 만약 메너페스트와 관련된 에러가 발생하면 Vista의 이벤트 뷰어에서 어플리케이션 폴더에 "SideBySide"라는 소스로해서 에러가 출력될 것이다.

만약 메너페스트를 EXE 또는 DLL에 임베딩시키지 않고 외부의 파일로 만든다면 다음과 같이 해서 특정 어플리케이션과 메너페스트를 연결해줘야 한다.

▷먼저 Exe 파일이 있는 디렉토리에 메너페스트 파일을 둬야 한다.

▷둘째 메너페스트 파일명은 반드시 "어플리케이션명.exe.manifest" 형태로 되어 있어야 한다.

만약 어떤 어플리케이션이 임베딩된 메너페스트와 외부의 파일로 존재하는 메너페스트를 모두 가지고 있다면 어떻게 될까. 그런 경우에는 Windows는 외부 메너페스트를 무시하고 내부 메너페스트만 사용하게 된다.

■ 기존 메너페스트 살펴보기

그럼, 지금 사용되고 있는 메너페스트를 한번 살펴보도록 하자. net.exe 프로그램에 임베딩된 메너페스트를 살펴보도록 할텐데 프로그램에 임베딩된 메너페스트를 보여줄 수 있는 프로그램이 필요하다. 임베딩된 메너페스트도 다른 리소스처럼 취급되는데 리소스 편집기를 이용해서 그 내용을 볼수 있다. 다음 링크를 따라가면 무료의 리소스 편집기를 얻을 수 있다. http://www.wilsonc.demon.co.uk 사이트를 통해서 얻을 수도 있고 "XN Resource Editor"라는 단어로 구글링해서 나오는 검색 결과를 통해서도 얻을 수 있다.

[그림] XN 리소스 편집기 실행 모습

[그림] net.exe를 로드한 XN 리소스 편집기 모습

메너페스트는 XML로 되어 있는데 지금 중요한 것은 다음과 같은 부분이다.

마이크로소프트의 명명 규칙에 익숙한 개발자들은 "requestExecutionLevel"을 "RequestExcutionLevel"로 바꾸고 싶겠지만 그렇게 하면 에러가 된다. xml에서는 대소문자를 구분한다는 것에  주의한다. 어트리뷰트 level의 값이 개발자가 관심이 있는 부분인데 이곳이 UAC에게 어플리케이션의 권한 상승이 필요한지를 알려줄 수 있는 부분이다. 이 값은 다음 3가지를 취할 수 있다.

asInvoker : 이 값을 이용하면 프로그램은 UAC에게 다음과 같은 내용을 전달하는 것으로 풀이할 수 있다:"나를 실행시킨 사용자가 가지고 있는 토큰을 그대로 사용해라" 프로그램을 로그온된 그대로의 계정을 사용해서 실행시킨면 일반 사용자 토큰을 사용하게 될 것이고 권한이 상승된 상태에서 프로그램을 실행시켰다면 관리자 토큰을 사용하게 될 것이다.

highestAvailable : 이 값은 "사용자가 가지고 있는 토큰중에서 가장 높은 권한을 토큰을 프로세스에 부여하라. 만약 필요하다면 동의 확인창(Consent UI)을 띄워서 필요한 레벨의 토큰을 구해라"라는 의미를 UAC에 전달한다.

requireAdministrator : 이것은 "highestAvailable"과 같지만 관리자 권한이 토큰이 필수적으로 필요하다는 의미이다. "사용자가 가지고 있는 토큰중에는 반드시 관리자 토큰이 있어야 한다. 그렇지 않으면 사용자에게 물을 필요도 없이 어플리케이션 실행을 그만 둬라"라는 의미이다.

마지막 두 값의 차이점은 뭘까. 하나의 토큰은 분리된 권한을 가지고 있을 수 있다. 그러나 두 토큰이 모두 관리자 권한의 토큰이 아닐 수 있다( 사실 어떻게 그렇게 될 수 있는 지에 대해서는 달봉이도 모른다.) 따라서 가장 높은 토큰을 사용한다고 해도 관리자 토큰이 아닐 수도 있다. 그래서 만약 어플리케이션을 관리자 권한의 토큰으로 실행시키고자 한다면 반드시 level="requireAdministrator"로 설정해야 한다.

프로그램을 어떤 토큰으로 실행시켜야 하는지에 대한 의도를 Vista에 알리는 메커니즘을 알았다. 그럼 이제 실제로 어떻게 하면 메너페스트 내용을 UAC가 알 수 있도록 하나. 세가지 방법이 있을 수 있다.

▶리소스 편집기로 메너페스트 추가하기

1) XN 리소스 편집기를 실행시킨다.

2) Add Resource 선택->리소스 선택창에서 "XP Theme Manifest" 선택

[그림] XN 리소스 편집기_리소스 추가

3) 기본적으로 오른쪽 창에 나타나는 코드를 선택해서 모두 지운다.

4) 오른쪽 창에 다음 코드를 붙여넣기 한다.

5) 편집된 리소스를 저장한다.

▶외부 파일로 메너페스트 정보 추가하기

두번째 방법은 훨씬 더 쉽다. "어플리케이션.exe.manifest"라는 이름으로 텍스트 파일을 만들어서 첫번째 방법에서 보여준 XML 내용을 그 파일에 옮겨놓고 저장한다. 그런 다음 그 파일을 실행파일이 있는 곳에 둔다. 그럼 Vista는 임베딩된 메너페스트 내용이 없는 경우 외부의 메너페스트 파일을 읽어서 사용하게 된다.

▶메너페스트 툴(mt.exe)로 메너페스트 임베딩하기

세번째 방법은 커맨드 라인툴을 사용해서 외부에 있는 메너페스트 파일의 내용을 EXE 어셈블리에 임베딩시키는 방법이다. 만약 이미 다른 메너페스트 내용이 있다면 기존 것을 덮어쓰게 될 것이다. mt.exe라는 커맨드 라인툴을 이용하게 되는데 마이크로소프트에서 얻거나 또는 Windows Platform SDK에 함께 배포되므로 SDK를 설치했다면 바로 사용할 수 있을 것이다.

커맨드 프롬프트 창에서 다음과 같은 형식으로 작업을 해 주면 된다.

mt /manifest 메너페스트파일이름 /outputresource:실행파일이름;#1

이 명령은 실행파일의 1번 노드의 메너페스트(앞의 XN 리소스 편집기의 좌측 창에 1번이라는 번호의 메너페스트 노드가 있다)로 지정한 메너페스트 파일의 내용을 저장한다. 커맨드의 모양이 약간 어색하기는 하지만 공백을 그대로 유지해야 한다. 예를 들어 다음과 같은 모양이 될 것이다.

mt /manifest example.exemanifest /outputresource:simple.exe;#1

이제 simple.exe 파일을 실행시킬때마다 사용자는 항상 권한 상승에 대한 동의 확인창이 뜨는 것을 경험하게 된다.

그런데 메너페스트 내용을 임베딩하는 것에는 문제가 있다.

■ 메너페스트의 강제 임베딩에 대한 문제점

만약 어플리케이션을 전자 서명했다면 문제가 된다. 어플리케이션에 전자 서명을 추가하게 되면 어플리케이션이 배포될 당시의 순수했던 코드가 나중에 어떤 악의를 가진 자로부터의 수정이 일어났는지를 확인을 할 수 있게 된다. 전자 서명된 어플리케이션에 메너페스트 내용을 임베딩하게 되면 결국 배포 당시의 코드가 외부로부터 수정되는 것과 마찬가지가 된다. 결국 어플리케이션을 실행하게 되면 Vista에서는 불평을 늘어놓고 어플리케이션은 실행되지 않게 된다.

Administrator Approval Mode의 관리자는 로그온을 하게 되면 일반 사용자 계정의 토큰을 사용하게 된다는 것은 이제 이해했다. UAC의 사정이 이러하므로 관리자 권한이 필요한 어플리케이션을 시작할때는 반드시 Windows에 관리자 토큰을 사용하도록 말해 줄 필요가 있다. 그렇지 않으면 Windows는 아무 생각없이 일반 사용자 토큰으로 프로그램을 시작할 것이고 그러다가 관리자 권한이 필요한 부분에서는 권한 부족으로 프로그램이 작동하지 않게 될 것이다. 이 포스트에서는 Windows에 관리자 토큰을 사용하도록 일러주는 방법으로서 사용자가 직접 조치를 취하는 방법을 알아본다. 그리고 다음 포스트에서는 사용자가 직접 일러주지 않더라도 Windows가 자동으로 인식해서 관리자 토큰을 사용할 수 있도록 하는 방법을 알아본다.

참고로 이렇게 관리자 토큰을 사용하게 됨으로써 사용자 권한이 관리자 권한으로 권한 레벨이 높아지는 것을 권한 상승(elevation)이라는 용어로 표현한다.

■ GUI에서 "관리자 권한으로 실행"

이 방법은 이미 이전 포스트에서 설명한 방 있다. 링크된 페이지에서는 실행할 프로그램을 cmd.exe로 했지만, 다른 프로그램들에도 해당하는 일반적인 방법이다.  링크 페이지에서 봤던 것은 사용자가 직접 실행파일을 오른쪽 클릭해서 나타나는 메뉴중에서 "관리자 권한으로 실행"을 선택하는 방법이다.

■ 커맨드창에서 "관리자 권한으로 실행"

이 방법은 커맨드 프롬프트창에서 RunAs 명령어를 사용해서 해당 프로그램을 관리자 권한으로 실행시킬 수 있다. 다음과 같은 형식으로 실행하면 된다.

"runas /user:<UserName> 프로그램"

암호를 입력하면 관리자 권한으로 프로그램이 실행된다.

■ 간단한 권한 상승 팁

만약 어떤 프로그램을 관리자 권한으로 실행시켜야 하는 경우가 많다면 매번 오른쪽 클릭해서 "관리자 권한으로 실행" 메뉴를 선택하는 것이 번거로울 수도 있다. 다음은 이런 경우 오른쪽 클릭을 하지 않더라도 바로가기를 클릭할때마다 관리자 권한으로 실행할 수 있는 방법이다.

1. 시작 메뉴의 오른쪽 클릭

2. "탐색" 클릭

3. "프로그램->보조프로그램"폴더를 선택

4. 오른쪽 클릭->새로만들기->바로가기 선택

5. "항목 위치 입력"란에 cmd.exe 프로그램을 찾아서 경로를 입력한다( "C:\Windows\System32\cmd.exe" )

6. 바로가기에 대한 이름을 "관리자 권한의 명령 프롬프트"라고 입력한다.

7. 생성된 바로 가기를 오른쪽 클릭해서 속성창을 띄운다.

[그림] "관리자 권한의 명령 프롬프트"의 바로가기 속성창

[그림] 고급 속성창

이 창에서 "관리자 권한으로 실행"을 선택합니다.

8. 다음은 결과이다.

[그림] 바로가기 생성된 결과

시작->모든 프로그램->보조프로그램을 보면 그림처럼 생성된 모습을 볼 수 있다. 바로가기 링크를 클릭하면 바로 동의 확이(Consent UI)창이 뜬다.

■ 이전 Windows 어플리케이션의 권한 상승

앞의 방법은 "시작" 메뉴에 있는 모든 바로가기에 대한 것이다. 만약 특별한 EXE 프로그램에 대해서 같은 작업을 해 주려면 약간 다른 UI를 보게 될 것이다. 프로그램의 오른쪽 클릭 속성창의 호환성 탭을 선택하면 그림과 같은 창이 뜬다.

[그림] 이전 Windows 어플리케이션 속성창

"관리자 권한으로 이 프로그램 실행"을 체크하면 프로그램을 더블 클릭할때마다 관리자 권한으로 프로그램을 실행시키게 된다. 그러나 해당 계정이 아닌 다른 계정으로 로그온해서 실행하면 그 설정이 적용되지 않는다. 만약 모든 계정에 대해서 설정이 적용되도록 하고 싶다면 밑의 "모든 사용자에 대한 설정 표시"를 클릭한다. 그럼 호환성 탭 페이지와 비슷한 창이 또 뜨고 그곳의 "관리자 권한으로 이 프로그램 실행"을 체크하면 된다.

개발자라면 이 포스트의 내용보다는 다음 포스트에서 전달할 내용에 더 관심이 있을 것이다. 즉 어떻게 하면 프로그램을 실행시킬때 자동으로 관리자 권한으로 실행시킬 수 있는가에 대한 이야기다.

앞의 포스트를 요약해보면 다음과 같다. "관리자 권한이 필요한 프로그램이 권한 관련해서 에러없이 실행되도록 하려면, 1) 사용자가 관리자 계정으로 프로그램을 실행시키든지 2) 프로그램 자체가 관리자 계정으로 실행되어야 한다는 것을 Windows에게 알려줄 수 있어야 한다. 여기까지는 나름대로 깔끔한 정리이다. 그러나 구체적으로, 언제 UAC에게 언제 어떻게 관리자 토큰을 사용하라고 일러줄 수 있는지에 대한 질문들이 남아있다. 그 질문에 대한 답을 바로 들어가기 전에 이 포스트에서는 토큰(token)의 구조를 좀 더 깊게 알아보자. 어떻게 보면 프로그래밍과는 직접적인 관계는 없으나 보안과 관련된 지식으로써 알아두면 나중에라도 도움이 될 것이다.

토큰(Token)의 구조

토큰은 사용자가 로그온을 하게 되면 그 사용자를 대표해서 컴퓨터의 RAM에 자리를 잡게되는 데이터 구조를 말한다.  Vista 토큰도 이전 Windows의 토큰과 비슷한 구조로서 몇개의 항목으로 구성된다 : 사용자 이름, 사용자 그룹 멤버쉽, 사용자 권한, Windows integrity level.

[그림] 토큰 구성 요소

전문가의 눈에는 달봉이의 Windows 보안에 대한 지식이 초보 수준일 것이다. 그러나 개발자 입장에서 토큰이 뭣이고 어떤 구조로 되어 있는가를 개략적으로나마 이해하는 것은 UAC를 이해하는 데 있어서 중요한 문제일 것이라 본다.

■ 사용자 이름 : Security ID(SID)

물론 컴퓨터 내부에서는 실제의 사용자 이름을 사용하지는 않는다. 실세계에서는 동명이인이 있을 수 있지만, Windows에서는 고유해야 하고 그것을 이름하여 Security ID 즉 SID라고 한다. 사용자나 그룹의 SID는 다음과 같은 모양으로 되어 있다.

S-1-5-21-domainID - relativeID

여기서 domainID는 사용자 계정의 위치 즉 특정 도메인이나 머신을 나타내는 96bit 숫자이고 relativeID는 그 위치에서의 특정 계정을 구분하는 숫자이다. 도메인이 생성되면 이전에도 없었고 앞으로도 없을 고유한 ID가 그 도메인에 부여된다. 그 값을 비록 있을 수 없는 숫자이지만 "12345"라고 하자. 그럼 그 도메인에 생성되는 달봉이 계정에는 다음과 같은 모양의 SID가 부여될 것이다: "S-1-5-21-12345-relativeID". relativeID는 1000부터 시작하게 되는데 첫번째 사용자 달봉이 계정이 생성되면 그 SID는 "S-1-5-21-12345-1000"이 되고 그 다음 사용자는 "S-1-5-21-12345-1001"이 될 것이다. SID를 생성하는 규칙은 좀 더 복잡하지만 하여튼 컴퓨터 관점에서는 이 SID를 통해서 컴퓨터 계정이든 사용자 계정을 구분하게 된다.

만약 달봉이가 어떤 파일이나 폴더에 대해 특별한 권한(permission)을 가지고 있다면 NTFS에는 "달봉이가 C:\dalbongstuff에 풀권한을 갖는다"라고 저장되지 않는다. 대신에 "S-1-5-21-12345-r1000이 C:\dalbongstuff에 풀권한을 갖는다"라고 표현되어 저장된다(물론 "풀권한을 갖는다"고 텍스트로 저장되지는 않는다 ^^).

가끔 보면 rights , privilages, permissions이 모두 권한으로 번역되는 문서가 있다. 대체 이것들은 어떤 차이가 있을까. 달봉이도 평소 아무 생각없이 쓰다 함 의미를 정확인 구분해 보고 싶었다. 검색을 하다가 마이크로소프트에서 해당 용어들을 정의해 놓은 페이지를 찾았다. 간단하게 요약하자면 이렇다. 우선 이 세 용어는 다음처럼 분류될 수 있다.  permissions과 User Rights로 분류되고 User Rights는 다시 Logon Rights와 Privileges로 나뉜다. Permission은 파일이나 폴더가 같은 특정 개체에 대해서 오퍼레이션을 수행할 수 있는 권한을 말하고 User rights는 컴퓨터의 특정 개체보다는 컴퓨터 전체에 영향을 미칠 수 있는 오퍼레이션을 수행할 수 있는 권한을 말한다. 그 중에서 Logon rights는 사용자 또는 보안 주체(security principals)에 대해서 어떤 로그온 방식을 제어할 것인가를 결정한다. 그리고 그 외의 사용자 권한으로 privilegs는 어떤 사용자가 컴퓨터 전체에 영향을 미칠 수 있는 리소스 조작을 할 수 있는지를 결정한다. permission은 개체를 소유하고 있는 소유자에 의해서 설정되며 그 권한 정보는 개체별로 저장된다. 반면에 User rights는 컴퓨터의 전체적인 보안 정책(security policy) 설정을 통해서 저장된다. 앞에서 소개한 링크 페이지에서 이것들에 대한 샘플 권한들을 보면 좀 더 그 차이를 알 수 있게 된다.

■ 사용자 그룹 멤버십 : SID 목록

토큰은 SID 뒤에 사용자가 멤버로 등록되어 있는 그룹들에 대한 목록 정보를 가지고 있다.

Domain-based global groups

Domain-based univeral groups

Domain-based domain local groups

Built-in local groups( Administrators, User groups)

기타 사용자가 시스템에 추가하는 로컬 그룹  등

■ 사용자 권한(Privileges) : What You Can Do

Windows는 사용자에게 파일이나 폴더같은 특정 객체에 접근해서 읽고 쓸 수 있는 권한을 허용할뿐만 아니라 컴퓨터 전체를 상태로 해서 어떤 일을 할 수 있는 권한도 부여한다. 특정 개체에 대한 권한을 permission이라고 한다면 이처럼 어떤 작업(task)를 수행할 수 있는 권한을 previlege라고 한다. 앞에서 소개한 링크 페이지를 참조하라.  이 privilege를 표현할때는 보통 문서에서는 두 가지 방식으로 표현한다. 하나는 텍스트 기반의 설명이고 다른 하나는 "SeXXX"형태의 짧은 이름이다. Vista에서는 이전 Windows에서 사용하던 privilegs 표현을 그대로 사용하고 있고, 예를 보면 다음과 같다.

SeShutdownPrivilge : 시스템을 종료할 수 있는 권한

SeBackupPrivilege와 SeResotrePrivilege : 파일, 폴더를 복사하고 복원할 수 있는 권한.

이전의 Windows에서 사용한 것을 많은 부분 그대로 이어받아서 Vista에서는 미리 정의된 34가지 유형의 privileges와 10가지의 logon rights를 정의하고 있다.  이중에서 UAC는 보안적인 측면에서 안전한 5가지 privilegs만 허용한다. 여기서는 개념적으로만 이해하고 구체적으로 어떤 privileges가 있고 그 중에서 어떤 것들이 UAC하의 사용자 계정에 부여되었는지는 다른 문서를 참고하도록 한다.

■ Windows Integrity Level

이것은 이전 Windows에서는 없던 토큰의 새로운 구성요소이다. Windows가 사용자를 "어느정도 신뢰하는가"를 나타내는 값이다. 이 신뢰도를 마이크로소프트에서는 Integrity라는 단어로 표현하고 있다. 신뢰도는 6단계로 구분되지만 UAC와 관련해서는 두 단계 "medium", "high" Windows Integrity Level만 사용된다. 일반 사용자 계정은 medium레벨을 얻게되고, 관리자는 high 레벨을 얻게 된다. SID의 표현중에서 "S-1-16-value"와 같은 부분이 Windows Interity Level을 나타내는 부분이다. 여기서 value는 medium인 경우는 8192, high인 경우는 12,288로 표현된다. Windows Integrity Level를 제어한다는 개념(WIC, Windows Integriy Control)도 Vista에서 나온 새로운 개념으로 할 말이 꽤 있는 모양이다. 

■ 사용자 토큰 정보를 알아보자.

토큰이 이런 구성 요소들로 이뤄졌다고 것이고, Vita에서는 이런 토큰을 살펴 볼 수 있는 커맨드 라인 툴을 제공해 주고 있다. 커맨드 프롬프트창을 실행시켜 다음 명령을 수행하면 내가 로그온한 후 생성된 토큰의 모양을 볼 수 있다.

whoami /user

[그림] 일반 사용자 계정의 SID 정보

사용자 계정이 속한 그룹에 대한 정보를 보고 싶다면 다음 명령어를 입력한다.

whoami /groups

[그림] 그룹 정보

그림을 보면 "Manatory Label\Meduum Manatory Level"로서  "S-1-16-8192"로 출력된다. 즉 "Windows Integrity level"이 "medium"이라는 Vista식 표현이다.  그리고 "BUILTIN\Administrators"그룹의 특성의 값이 "거부 대해서만 그룹 사용"이라고 표시되어 있다. 즉 일반 사용자 토큰으로 로그온한 경우는 "deny"인 경우만 Administrators그룹에 속한 것이다라는 얘기다. 말이 좀 이상하게 들릴지 모르지만 이 얘기는 UAC가 일반 사용자 토큰에서는 "BUILTIN\Administrators" 그룹의 멤버십을 없앴다는 얘기로 보면 된다.

사용자 권한을 알아볼 수도 있다.

whoami /priv

[그림] 사용자 권한

앞에서 본 명령을 이제 "관리자 권한으로 실행"된 프롬프트창에서 실행해본다. 그리고 그 값들을 앞에서의 결과들과 비교해 본다. Elevated된 후의 정보들이 출력됨을 볼 수 있을 것이다.

[그림] 권한 상승 후의 사용자 SID

권한 상승후 라도 현재 로그인한 사용자가 변경된 것은 아니다. 해서 이미 로그온한 사용자의 사용자 계정 정보는 변함없다.

"관리자 권한으로 실행"된 프롬프트창에서 whoami /groups를 실행시켜보면 다음과 같은 결과가 나온다.

[그림] 권한 상승후의 Windows Integrity Level 값

관리자 권한으로 명령 프롬프트창을 실행한 후를 보면 "Mandatory Label\High Mandatory Level임을 알수 있다.  그리고 "BUILTIN\Administrators"그룹에 대해서 특성값을 보면 "필수 그룹, 기본값으로 사용 가능"으로 되어 있다. 이 얘기는 "BUILTIN\Administrators"그룹의 멤버십과 권한을 복원했다고 보면 된다.

이제 다음 포스트에서는 사용자가 프로그램을 관리자 권한으로 실행하는 일반적인 방법 그리고 아마 그 다음 포스트에서는 개발자들이 프로그램을 개발할때 관리자 권한이 필요하다는 것을 Vista에게 알리도록 표시하는 방법을 알아보게 될 것이다.

Vista에서는 일반 사용자(Administrators 그룹에 속한 사용자 포함)는 시스템에서 보호되는 디렉토리 또는 레지스트리에 직접 쓰지 못하도록 하고 있다. 보호받는 디렉토리와 레지스트리 경로는 다음과 같다.

(%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(서브디렉토리)

HKEY_LOCAL_MACHINE\SOFTWARE

그럼, 기존에 이런 곳에 접근해서 데이터를 저장하고 있는 어플리케이션은 모두 사용할 수 없게 되는 것인가.

Vista에서는 "임시"로 이런 어플리케이션의 호환성을 위하여 가상화 기술을 도입하고 있다. 어플리케이션에서 보호받는 디렉토리와 레지스트리에 데이터를 쓰려고 하면 Vista에서는 런타임시 그 경로를 사용자별 경로로 자동으로 변경시켜 준다. 

%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(서브디렉토리)
Redirect to: %LOCALAPPDATA%\VirtualStore

HKEY_LOCAL_MACHINE\SOFTWARE
Redirect to: HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry Keys> 

어플리케이션에서는 보호받는 디렉토리, 레지스트리에 값을 쓰지만, 런타임시 Vista에서는 그것을 사용자별로 각자의 경로로 리다이렉트해서 그곳에 값을 쓴다는 얘기다. 다음 샘플 프로그램을 보자. 

이 프로그램을 실행하는 계정은 물론 일반 사용자 계정이라고 하자. Program Files의 물리적 경로와  "dalbong2.txt"를 결합해서 Console로 출력한다. 그 값은 다음과 같다.

[그림] 프로그램상에서 인식하는 파일 경로

Program Files 폴더에 dalbong2.txt를 생성하겠다는 것인데, 그러나 실제 파일은 이곳에 저장되지 않는다. 프로그램으로부터 이 요청을 받으면 Vista에서는 다음 경로로 리다이렉트를 해서 파일을 저장한다.

[그림] 실제 저장 경로

파일이 실제 생성된 곳의 경로는 그림에서처럼 보는 바와 같다. 일반 사용자는 Program Files 폴더에 접근할 수 없기 때문에 에러가 발생하고 Vista에서는 가상화를 통해서 사용자별로 가상 디렉토리에 파일을 생성하게 되는 것이다. 그러나 만일 실행 파일을 관리자 권한으로 실행시킨다면 실제 "C:\Program Files\dalbong2.txt"로 저장될 것이다.

가상화는 앞에서 언급한 대로 레거시 어플리케이션과의 호환성을 위해서 취하고 있는 "임시" 기능이다.  64비트의 환경에서는 이 기능은 사라진다.

그룹 정책 편집기를 실행시켜 보면 현재 내 PC에 설정된 정책 내용을 볼 수 있는데, 이곳에서 UAC 정책 설정 내용도 볼 수 있다.

"시작->검색 시작->gpedit.msc"

"로컬 컴퓨터 정책->컴퓨터 구성->Windows 설정->보안설정->로컬 정책->보안 옵션"을 선택하면 그림과 같은 내용의 UAC 설정을 볼 수 있다.

[그림] 내 PC의 UAC 정책 설정

이 설정 내용을 보면 UAC에 의해서 어떤 일들이 일어나는지를 알 수 있고 그래서 UAC 개념에 대한 이해에도 도움이 될 것이다. 다음은 각 정책을 더블 클릭했을 때 나오는 설명들로서, 몇가지 확인해봐야 하는 내용도 있지만 그대로 복사해 놓고 있다.

Administrators 그룹에 속한 관리자와 기본 제공 관리자(Built-in Administrator)는 구분된다. 기본 제공 관리자는 UAC의 적용을 받지 않는다(Administrator 여부를 체크하지 않는다기 보다는). 따라서 높은 권한을 필요로 하는 프로세스를 실행시키더라도 보안창을 띄우지 않는다. 그러나 기본 제공 관리자 계정으로 로그온하는 것은 Vista에서는 비추천이다.

하여튼, 처음 Vista를 설치해서 로그인을 하려고 하면 Administrator 계정이 보이지 않는다. 달봉이는 약간 당황했다.

[그림] 로그온 계정

Vista에서는 기본적으로 이  관리자 계정은 사용하지 못하도록 설정되어 있다. 이 계정이 나타나도록 하려면 설정을 하나 변경해야 한다.

시작->실행-> gpedit.msc (Vista에서는 검색 시작 박스를 사용해도 된다. 달봉이는 지금까지 실행 창을 사용했는데...)

관리자 승인을 확인하는 UAC 보안창이 뜨고 계속을 클릭하면, 그룹 정책을 편집할 수 있는 창이 뜬다.

좌측의 로컬 컴퓨터 정책 트리에서, 컴퓨터구성->Windows 설정->보안 설정->로컬 정책->보안 옵션을 선택하면 오른쪽에서처럼 현재 설정된 여러 정책들을 볼 수 있다.

여기서 그림에서 선택된 정책 "계정:Administrator 계정 상태" 의 보안설정 값이 기본적으로 "사용 안 함"으로 되어 있다. 정책 레코드를 더블 클릭해서 "사용"으로 선택하면 다음 로그인부터는 Administrator 계정을 로그온시 볼 수 있게 된다.

Aministrator 계정을 이렇게 하면 볼 수 있다는 것이지 Administrator 계정을 사용하라는 얘기는 아님!