Windows Vista UAC(2) - How UAC Works(1)

be smart | 딥프리
http://blog.naver.com/myfancy/140033487213

Windows Vista User Account Control  (UAC)

 

이 글은 Microsoft Windows Vista UAC개발 정보에서 다운로드한 Top 10 Ways to Light Up Your Windows Vista Apps의 UAC(User Account Control)부분에 대해 살펴본 내용이다.

 

첫번째 글에 이어 Windows Vista의 새로운 UAC기술에 대해 어떤 구조로 어떻게 동작하는지 살펴보자.

 

New Technologies for Windows Vista

 

아래의 섹션은 인스톨러 검출, Windows Installer 4.0을 이용한 일반사용자의 패치, 유저인터페이스 권한 격리, 그리고 가상화를 포함한 Windows Vista의 새로운 기술을 자세히 살펴본다.

 

ActiveX Installer Service

 

AvtiveX 설치 서비스는 기업이 ActiveX컨트롤 설지를 일반유저에게 위임할 수 있게 해준다. 이 서비스는 일반적인 업무 작업이 실패한 ActiveX 컨트롤 설치에 방해받지 않고 업데이트하는 것을 보증합니다. Windows Vista는 또한 IT전문가가 일반유저가 ActiveX컨트롤들을 인스톨 할 수 있는 Host URL들을 정의할 수 있게 해주는 그룹 정책 설정을 포함하고 있습니다. ActiveX 설치 서비스는 Windows 서비스, 그룹 정책 관리 템플릿 그리고 인터넷익스플로러의 일부 변화로 구성됩니다. 그리고, 그것이 설치된 클라이언트에서만 활성화되는 선택적인 컴포넌트 입니다.

 

Installer Detection

 

인스톨 프로그램은 소프트웨어를 배포하기위해 디자인된 어플리케이션입니다. 그리고, 대게 시스템 디렉토리과 레지스트리 키들에 값을 기록합니다. 이 보호된 시스템 위치들은 전형적으로 관리자 유저에게만 쓰기가 가능합니다. 이것은 일반 유저는 프로그램을 인스톨하기 위한 충분한 엑세스 권한을 가지지 않았다는 말입니다. Windows Vista는 설치 프로그램들을 발견적으로 검출하고, 엑세스 권한을 가지고 실행하도록 관리 자격 또는 승인을 요청합니다. Windows Vista는 또한 업데이터와 언인스톨 프로그램들을 발견적으로 검출합니다. UAC의 디자인 목표는 설치프로그램들은 파일시스템과 레지스트리의 보호된 영역에 기록하기 때문에 유저의 인지와 동의 없이 실행되는 설치를 막는 것임을 주지해야 합니다.

[중요: 새로운 설치 프로그램을 개발할때, Windows Vista용 프로그램을 개발하듯이, 적당한 requestedExecutionLevel요소를 포함한 Application manifest를 반듯이 포함시켜야 한다. (6단계 : Application Manifest (UAC)를 만들고 포함하기 참고). 포함된 Application Manifest에 requestedExecutionLevel이 포함된 경우, 인스톨러 검출을 덮어쓰게 됩니다.]

 

인스톨러 검출은 아래의 경우에만 적용됩니다.

 

1. 32비트로 실행가능한 경우

2. requestedExecutionLevel이 없는 어플리케이션

3. LUA가 활성화되고 일반유저로 실행중인 인터랙티브 프로세스들

 

32비트 프로세스가 생성되기 전에, 인스톨러인지 아닌지 결정하기 위해 아래의 속성들이 체크됩니다.

- 파일명이 "install", "setup", "update" 등과 같은 키워드를 포함하는지

- 다음의 버전 부여 리소스 필드에서의 키워드 : Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, Export Name

- 실행파일에 포함된 나란히 있는 manifest에서의 키워드

- 실행파일에 링크된 특정 StringTable 엔트리에서의 키워드

- 실행파일에 링크된 RC data에서의 키 속성

- 실행파일내의 타겟된 바이트 순서

[Note: 키워드와 바이트순서는 다양한 인스톨러 기술에서 관찰된 일반적인 특성에서 도출됨]

 

"6단계 : Application Manifest (UAC)를 만들고 포함하기"를 포함해서, 이문서 전체를 리뷰하세요.

[Note: User Account Control : Detect application installations and prompt for elevation 설정은 인스톨러 검출기가 인스톨 프로그램을 검출하기 위해서 반드시 활성화 되어 있어야 합니다. 이 설정은 기본적으로 활성화 되어 있습니다. 그리고 보안정책관리자 스냅인(secpol.msc) 또는 그룹정책(gpedit.msc)에서 설정 할 수 있습니다.]

 

Microsoft Windows Installer의 일반적 정보와 개관은 MSDN(http://go.microsoft.com/fwlink/?LinkId=30197)을 참고하세요.

 

 

Patching Application in a UAC Environment

 

MS Windows Installer 4.0은 어플리케이션 설치와 패치를 더욱 쉽게 만들기 위한 생각으로 디자인 되었습니다. Windows Installer 4.0의 도입으로, 새로운 버전을 재인스톨 하지 않고, 어플리케이션에 패치를 적용할 수 있습니다. 이 방법은 한컴퓨터에 설치 배포된 어플리케이션을 관리자 접근 토큰의 획득 없이 사용자가 패치해야 할 경우 이상적입니다. 어떻게 어플리케이션에 패치를 적용하고 생성하는지의 정보는 MSDN(http://go.microsoft.com/fwlink/?LinkId=71492)을 참고하세요.

 

Security Center Inregration

 

UAC가 Windows Vista 컴퓨터에서 비활성화 되어 있는 경우, 보안센터는 사용자에게 UAC를 다시 활성화 하도록 경고하고, 물어봅니다. UAC 설정이 변경되고, 컴퓨터가 재시작되었을때 보안센터는 이 경고를 한번 표시합니다.

 

User Interface Privilege Isolation

 

유저인터페이스 특권 격리(UIPI)는 같은 Interactive Desktop에서 관리자보다 낮은 계정으로 실행되고 있는 프로세스로 부터 전체 관리자 권한으로 실행되고 있는 어플리케이션을 격리하는것을 도와주는 메카니즘이다. UIPI는 윈도우와 유저인터페이스를 지원하는 USER라고 알려진 그래픽 서브시스템과 윈도우를 하는것(Windowing)에 특유(specific)합니다. UIPI는 보다 낮은 권한의 어플리케이션에서 한 프로세스가 더 높은 권한의 프로세스로 입력값을 보내기 위해 Windows Message를 사용하는 것을 막습니다. 어떤 프로세스에서 다른 프로세스로 입력을 보내는 것은, 사용자가 키보드 또는 마우스의 액션을 제공하지 않아도, 다른 프로세스에 입력을 주입하는 것을 가능하게 합니다.

 

UIPI 뒤의 개념은 간단합니다. Windows Vista는 계층적 방법으로 유저 인터페이스 특권 레벨 세트를 정의합니다. 레벨의 동작은 보다 높은 특권 레벨에서 더 낮은 레벨로 실행되는 어플리케이션에 윈도우 메세지는 보낼 수 있습니다. 그렇지만, 보다 낮은 레벨은 보다 높은 레벨의 어플리케이션 윈도우에 윈도우 메세지는 보낼 수 없습니다.

 

유저 인터페이스 특권 레벨은 프로세스 레벨에 있습니다. 프로세스가 초기화될 때, 프로세스의 보안 엑세스 토큰에 지정된 데스트톱 보전(integrity) 레벨을 결정하기 위해 유저 서브시스템은 보안 서브시스템을 호출합니다. 프로세스가 생성되고 변하지 않는 경우 데스크톱 보전(integrity) 레벨은 보안 서브시스템에 의해서 설정됩니다. 따라서 프로세스가 생성되고 변하지 않는 경우, 유저 인터페이스 특권 레벨은 또한 유저 서브시스템에 의해서 설정됩니다.

 

일반 유저에 의해서 실행되는 모든 어플리케이션은 같은 유저 인터페이스 특권 레벨을 가집니다. 일반유저로서의 어플리케이션은 단일 특권 레벨에서 실행됩니다. UIPI는 같은 특권 레벨의 어플리케이션간의 윈도우 메세징 동작을 변경하거나 방해하지 않습니다. UIPI는 관리자 그룹의 멤버이고, 같은 데스크톱에서 일반유저로 어플리세이션을 실행하고 또한 전체 관리자 엑세스 토큰으로 프로세스를 실행하는 사용자에게 영향을 주게됩니다. UIPI는 다음의 동작을 막는것으로 더 높은 특권 프로세스에 낮은 프로세스가 접근하는 것을 막습니다.

 

낮은 특권의 프로세스가 할 수 없는 것:

- 높은 프로세스특권의 윈도우 핸들 검증 실행

- 높은 특권 어플리케이션 윈도우에 SendMessage또는 PostMessage 실행

  이런 응용프로그램 인터페이스 (APIs)는 성공을 반환하지만,

  조용하게 윈도우메세지는 버립니다.

- 높은 특권 프로세스에 붙이기(Attach)위해서 쓰레드 훅(Thread hooks)을 사용

- 높은 특권 프로세스를 모니터 하기위해, 저널 훅(Journal hooks)을 사용

- 높은 특권 프로세스에 동적 링크 라이브러리(DLL) 주입을 실행

 

활성화된 UIPI로, 다음의 USER 리소스는 여전히 특권레벨이 다른 프로세스에서도 공유됨:

- 실제로 스크린 표면을 소유하고 있는 데스크톱 윈도우

- 데스크톱 힙 읽기전용 공유메모리

- 전역 Atom 테이블

- 클립보드

 

스크린에 그리는 것은 UIPI에 의해서 방해받지 않는 다른 액션입니다. 예를 등어, 스크린에 그리는 것은 모니터와 같은 외부 출력장치에 내용을 표시하는 페인트 함수을 사용하는 과정에 언급합니다. USER/그래픽스 장치 인터페이스(GDI) 모델은 표면을 그리는 것에 대한 컨트롤을 허가하지 않습니다. 그러므로, 낮은 특권 어플리케이션이 높은 특권 어플리케이션 윈도우의 표면 영역위에 그리는 것이 가능합니다.

[Note: 윈도우즈 쉘(Explorer)는 일반사용자 프로세스로 실행되므로, 일반유저로 실행되는 모든 다른 프로세스는 여전히 거기에 키입력(Keystroke)을 보낼 수 있습니다. 이것은 Setup.exe를 더블클릭하거나, 권한상승쉴드 아이콘을 클릭하는 관리 액션을 시작하는 경우, 관리 승인 모드에서 관리자 계정이 권한상승동의를 요청받는 주요한 이유입니다.]

 

Virtualization

[중요: 가상화는 Windows Vista에서 일반유저로 실행되는 어플리케이션의 호환성 문제를 개선하기 위해 구현됩니다. 개발자는 윈도우의 다음의 버전에 있는 가상화게 의지하면 안됩니다.]

Windows Vista이전에는 많은 어플리케이션이 전형적으로 관리자에 의해서 실행되었습니다. 그 결과, 어플리케이션은 자유롭게 시스템, 파일 및 페지스트리 키를 읽고 쓰기 할 수 있습니다. 만약 이러한 어플리케이션이 일반 유저에 의해서 실행되면, 이것들은 불충분한 접근 권한때문에 실패할것입니다. 이런 유저들을 위해서 Windows Vista는 사용자 프로필내의 유저마다 가지는 위치에 기록하도록 리다이렉팅함으로써 어플리케이션 호환성을 향상합니다. 예를들면 어플리케이션이 C:\Program Files\Contoso\Settings.ini를 쓰려고 시도하고, 사용자가 그 디렉토리에 쓰기권한이 없다면, 쓰기작업은 C:\Users\<user name>\AppData\Local\ VirtualStore\Program Files\contoso\settings.ini로 리다이렉트 됩니다. 레지스트리를 위해서는, 어플리케이션이 HKEY_LOCAL_MACHINE\Software\Contoso\에 쓰려고 하면, 이것은 자동으로

HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\< User SID >_Classes\VirtualStore\Machine\Software\Contoso 으로 리다이렉트 됩니다.

 

다음의 그림은 Windows Vista의 가상화 프로세스를 자세히 보여줍니다. 이 예에서 데니스는 관리 승인 모드에서 관리자입니다. 그리고, 브라이언은 일반 유저입니다. 가상화는 파일가상화 및 레지스트리 가상화 2개의 컴포넌트로 구성됩니다.

  Virtualization Process

[중요: Windows Vista 프로그램을 개발하는 동안 가상화 파일과 레지스트리 키의 복잡성을 감소시키려면, 파일과 레지스트리 가상화를 끄기위해서 적절한 requestedExecutionLevel과 어플리케이션 매니페스트파일을 포함해야 합니다.]

 

가상화는 오직 다음을 위해 활성화 :

- 32비트 대화형(interactive) 프로세스

- 파일/폴더 및 레지스트리 키에 등록가능한 관리자

 

가상화는  다음을 위해 비활성화 :

- 64비트 프로세스

- 대화형이 아닌(Non-interactive) 프로세스

- 인격화된(impersonate) 프로세스

- 커널 모드 호출자

- requestedExecutionLevel을 가지고 있는 실행파일

 

가상화 및 로밍 :

- 가상화 파일/폴더 및 레지스트리 키는 로밍되지 않습니다. (로밍 프로파일 참조)

- 로밍되지 않는 전역객체와 결합된됩니다.

 

File Virtualization

 

파일가상화는 전형적으로 관리자만 쓸수 있는 시스템 위치에 설정 파일과 같은 파일을 저장할 수 있다고 신뢰하는 어플리케인션과 같은 상황을 다훕니다. 이 상황에서 일반유저로 프로그램을 실행하는 것은 엑세스 레벨이 충분하지 않아서 실패할 수도 있습니다.

 

어플리케이션이 관리자만 쓸수있는 시스템위치에 쓸때, Windows는 %LOCALAPPDATA%\VirtualStore에 위치한 가상저장 디렉토리아래의 유저별 경로에 이하의 모든파일 조작을 씁니다. 그 후 어플리케이션이 이 파일을 다시 읽을때, 시스템은 가상저장내의 것을 제공합니다. 어플리케이션의 도움없이 윈도우즈 보안 인프라스트럭쳐가 가상화를 처리하기 때문에, 어플리케이션은 Program FIles에 직접 읽고 쓸수 있다고 믿게 됩니다. 파일 가상화의 투명성은 실제로 가상화된 버전에 액세스하는 경우에도, 어플리케이션이 보호된 리소스에 쓰고 읽는다고 인식하게 하는것을 가능하게 합니다.

 

[Note: 당신이 폴더나 레지스트리에서 리소스를 열거하면, Windows Vista는 단일리스트에 글로벌 파일,폴더,레지스트리를 병합합니다. 이 병합 뷰에서 보호된 전역 리소스는 가상화된 리소스와 함께 리스트 됩니다.]

[중요: 버츄얼 복사본은 항상 어플리케이션에 최초로 전달됩니다. 예를들어 config.ini가 \ProgramFiles\App\config.ini와 %LOCALAPPDATA%\VirtualStore\config.ini에 있을때, \ProgramFiles\App\config.ini가 갱신되었다 할지라도, Virtual Store내의 config.ini가 항상 읽는 것이 됩니다.]

 

다음의 그림은 가상화된 리소스에 대해 어떻게 전역 그리고 병합된 뷰가 어떻게 다른 유저들에게 표시되는지를 보여줍니다.

  Virtualized resource and views

아래의 예는 파일 가상화 프로세스의 예입니다.

Syed Abbas(Woodgrove 은행에서 판매 대리인)은 다른 판매대리인과 공유하여 사용하는 컴퓨터에서 일반유저 계정으로 실행하고 있습니다. Syed는 Program Files\SalesV1\ 디렉토리의 \Program Files\SalesV1\SalesData.txt를 갱신하고 저장하기 위해 자주 스프레트시트 어플리케이션을 사용합니다. Program Files\SalesV1\는 보호되지만, 스프레드시트 어플리케이션의 관점에서는 Windows Vista의 가상화로 파일이 성공적으로 저장됩니다. 이렇게 하기위해, 파일은 Users\username\appdata\Virtual Store\Program Files\SalesV1\SalesData.txt로 리다이렉트 됩니다. Syed가 윈도우즈 탐색기를 열고, Program Files 디렉토리를 탐색하면, 그는 SalesData.txt파일의 전역 뷰를 보게 됩니다.

[Note: Syed가 그의 가상화 파일을 볼려면, 탐색기의 호환성 파일(Compatibility files) 버튼으로 Virtual Store을 탐색해야 합니다.]

 

그렇지만, Stuart Munson(다른 판매 대리인)이 이 워크스테이션에 로그인 한후, 그는 SalesData.txt파일이 Program Files\SalesV1\디렉토리에 보이지 않을 것입니다. 만약 다른 유저가 컴퓨터를 사용하고, \Program files\SalesV1\SalesData.txt 파일을 저장한다면, 그 파일 또한 사용자의 Virtual Store에 가장화 될것 입니다. Syed가 수정하고 저장하는 파일은 시스템의 다른  가상화 파일과는 독립되어 남아있게 됩니다.

 

Registry Virtualization

 

레지스트리 가상화는 HKEY_LOCAL_MACHINE\SOFTWARE 아래 레지스트리 키에 적용되는 것을 제외하면, 파일 가상화와 비슷합니다. 이 기능은 어플리케이션이 일반유저 계정으로 실행되는 경우에도 계속해서 HKEY_LOCAL_MACHINE\SOFTWARE 에  설정을 저장할 수 있도록합니다. 키와 데이터는 HKEY_CLASSES_ROOT\VirtualStore\SOFTWARE 로 리다이렉트 됩니다. 파일 가상화의 경우와 마찬가지로, 각 유저는 HKLM에 저장된 어플리케이션의 모든 값의 가상화된 복사본을 가지고 있습니다.

 

Registry Virtualization Details

- 소프트웨어 하이브(hive)의 각각의 키에서 On/Off

- 키레벨 가상화 컨트롤을 위한 reg.exe안의 새로운 FLAGS 옵션 :

   가상화 및 "열기 접근 권한 정책" 컨트롤의 재귀적인 활성/비활성을 할 수 있다.

- ZwQueryKey : 키를 위해 가상화 플래그를 프로그래밍적으로 쿼리

- 가상화는 Wow64 리디렉션 상에서 일어납니다.

- 64비트 및 32비트 레지스트리 뷰 양쪽에서 가능합니다.

   HKU\{SID}_Classes\VirtualStore\Machine\Software

   HKU\{SID}_Classes\VirtualStore\Machine\Software\SYSWOW3264

- 대부분의 레거시 32비트 어플리케이션은 32비트 뷰를 사용합니다.

 

Virtualization Recommendations

 

가상화는 오직 기존프로그램과의 적용 호환성을 돕기위한 것입니다. Windows Vista를 위해서 설계된 어플리케이션은 민감한 시스템 영역에 쓰기를 하지 말아야 합니다. 또한 올바르지 않은 어플리케이션 동작을 바로잡기위해(redress) 가상화에 의존해도 안됩니다. Windows Vista에서 실행되기 위해서 코드를 갱신하는 경우, 개발자는 런타임중에 어플리케이션이 유저별 위치 또는 컴퓨터의 엑세스 컨트롤 리스트(ACL) 설정을 적절히 설정한 %alluserprofile% (CSIDL_COMMON_APPDATA) 내의 위치에만 데이터를 저장하도록 해야 합니다.

[중요: MS는 보다 많은 어플리케이션이 Windows Vista로 마이그레이션됨과 동시에, Windows운영체제의 미래의 버전에서 가상화를 제거할 생각입니다. 예로 가상화는 64비트 어플리케이션에서는 동작하지 않습니다.]

- 당신의 대화형(interative) 어플리케이션을 위한 적절한 requestedExecutionLevel로 어플리케이션 매니페스트를 추가하세요. 이렇게 하면, 매니페스트된 어플리케이션의 가상화를 끄게됩니다.

- 프로세스간통신(IPC) 방법으로 레지스트리를 이용하지 마세요. 서비스 및 유저 어플리케이션은 다른 키 뷰를 가집니다.

- 어플리케이션을 Windows Vista에서 테스트 하세요 :

  일반 유저로 실행되는 프로세스가 %systemroot%같은 전역 네임스페이스에

  쓰지 않는 것을 확인하세요.

- 필터 드라이버 개발자를 위해 :

  당신의 높이(altitude) 범위를 확인하세요. (http://go.microsoft.com/fwlink/?LinkId=71503)

  파일스스템 필터와 fltmc.exe(http://go.microsoft.com/fwlink/?LinkId=71504)를 확인하세요.

  이것들은 FSFilter 가상화보다 높아야 합니다.

- 가상화된 리소스는 전역 리소스이 사용자당 복사본인것을 기억하세요.

 

Access Token Changes

 

Windows Vista 컴퓨터에 사용자가 로그인 하는 경우, 윈도우즈는 사용자가 두개의 엑세스 토큰(필터된 엑세스 토큰와 전체 엑세스 토큰)을 받는지를 결정하기 위해,  유저 계정이 소유하는 Administrative Windows Privileges와 Relative IDs(RIDs)를 봅니다. 아래 중 어느 한 경우 라면, 윈도우즈는 두개의 엑세스 토큰을 생성합니다.

 

1. 사용자 계정이 다음의 RIDs중 어떤것이라도 포함하는 경우

    DOMAIN_GROUP_RID_ADMINS

    DOMAIN_GROUP_RID_CONTROLLERS

    DOMAIN_GROUP_RID_CERT_ADMINS

    DOMAIN_GROUP_RID_SCHEMA_ADMINS

    DOMAIN_GROUP_RID_ENTERPRISE_ADMINS

    DOMAIN_GROUP_RID_POLICY_ADMINS

    DOMAIN_ALIAS_RID_ADMINS

    DOMAIN_ALIAS_RID_POWER_USERS

    DOMAIN_ALIAS_RID_ACCOUNT_OPS

    DOMAIN_ALIAS_RID_SYSTEM_OPS

    DOMAIN_ALIAS_RID_PRINT_OPS

    DOMAIN_ALIAS_RID_BACKUP_OPS

    DOMAIN_ALIAS_RID_RAS_SERVERS

    DOMAIN_ALIAS_RID_PREW2KCOMPACCESS

    DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS

    DOMAIN_ALIAS_RID_CRYPTO_OPERATORS

2. 사용자 계정이 일반 유저 계정의 특권이외의  어떤 특권을 포함하고 있는 경우

    일반 유저 계정은 오직 다음의 권한만을 가지고 있습니다.

    SeChangeNotifyPrivilege

    SeShutdownPrivilege

    SeUndockPrivilege

    SeIncreaseWorkingSetPrivilege

    SeTimeZonePrivilege

[Note: 필터된 토큰이 어떤 권한을 가지는지는 원래의 토큰이 위의 제한된 RIDs리스트의 어떤것을 포함하고 있는지에 따릅니다.

제한된 RID중 어떤것이 토큰에 있다면, 다음을 제외한 모든 권한이 삭제됩니다. :

    SeChangeNotifyPrivilege

    SeShutdownPrivilege

    SeUndockPrivilege

    SeReserveProcessorPrivilege

    SeTimeZonePrivilege

제한된 RID가 토큰에 없다면, 다음의 특권만 삭제 됩니다. :

    SeCreateTokenPrivilege

    SeTcbPrivilege

    SeTakeOwnershipPrivilege

    SeBackupPrivilege

    SeRestorePrivilege

    SeDebugPrivilege

    SeImpersonatePrivilege

    SeRelabelPrivilege
]

 

필터된 엑세스 토큰으로 불리우는 첫번째 토큰은 액세스토큰 및 이전에 리스트되지 않고, 삭된 관리상의 윈도우즈 권한에 USE_FOR_DENY_ONLY로 표시된 이전의 RIDs를 가집니다.(현재의 경우). 사용자가 어플리케이션을 시작할때, 필터된 엑세스 토큰이 기본적으로 사용됩니다. 링크된 엑세스 토큰으로 불리는 변경되지 않은 전체 엑세스 토큰은 필터된 엑세스 토큰에 연결(Attach)되고, 전체 관리 엑세스 토큰으로 어플리세이션을 시작하도록 하는 요청이 있는경우, 사용됩니다.

 

------------------------------------------------------------------------------------

첫번째 글에 이어 UAC와 관련된 변경사항들을 알아보았다.

개념을 잡는것이 중요한것 같다.

 

ActiveX Installer Service, Installer 검출, 패치의 적용, UIPI, 가상화, 엑세스토큰 변경등..

 

개념부터 알아두고, 실제로 기존의 ActiveX나 Apps를 어떻게 변경할것인가?

새로운 Vista용 Apps를 어떻게 디자인할 것인가를 차차 알아나가자..

 

그럼 다음에는 UAC의 구조에 대해 알아보자.

 

 

RID에 대한 자세한 정보는 MSDN을 참고하세요.

(http://go.microsoft.com/fwlink/?LinkId=71494)

 

Windows 권한에 대한 자세한 정보는 MSDN을 참고하세요.

(http://go.microsoft.com/fwlink/?LinkId=71495)