Microsoft MVP성태의 닷넷 이야기
Windows: 15. MIC 환경 구성 - Windows XP와 유사한 보안 설정 [링크 복사], [링크+제목 복사],
조회: 23247
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 8개 있습니다.)
Windows: 14. 보호 모드와 필수 무결성 제어(MIC: Mandatory Integrity Control)
; https://www.sysnet.pe.kr/2/0/433

Windows: 15. MIC 환경 구성 - Windows XP와 유사한 보안 설정
; https://www.sysnet.pe.kr/2/0/434

Windows: 16. 개발자를 위한 UAC 환경 설정
; https://www.sysnet.pe.kr/2/0/437

Windows: 17. 보안 데스크톱에서 활성화되지 않은 UAC 창이 안전할까?
; https://www.sysnet.pe.kr/2/0/441

Windows: 20. UAC 이모저모
; https://www.sysnet.pe.kr/2/0/449

Windows: 22. 가상화에 대해서.
; https://www.sysnet.pe.kr/2/0/456

.NET Framework: 297. 특정 EXE 파일의 실행을 Internet Explorer처럼 "Protected Mode"로 실행하는 방법
; https://www.sysnet.pe.kr/2/0/1225

개발 환경 구성: 571. UAC - 관리자 권한 없이 UIPI 제약을 없애는 방법
; https://www.sysnet.pe.kr/2/0/12633





MIC 환경 구성 - Windows XP와 유사한 보안 설정


자, 지난번 "보호 모드와 필수 무결성 제어(신뢰도 등급)(MIC: Mandatory Integrity Control)"을 통해서 MIC에 대해 어느 정도 감이 잡혔을 것이라 봅니다. 그렇다면 이제 재미있는 장난을 한번 해볼까요? ^^ 바로, 비스타를 "Windows XP"에서 쓰던 것처럼 보안을 완전히 해제하고 사용할 수 있도록 해보자는 것입니다. 사실, 별다른 설정을 하는 것은 아니고 단지 지난번 "보호 모드와 필수 무결성 제어(신뢰도 등급)(MIC: Mandatory Integrity Control)" 이야기를 제대로 이해하셨다면 그 방법을 눈치채실 수 있는 정도입니다.

비스타는, 결국 보안이 필요한 모든 시스템 리소스에 MIC를 적용한 운영체제라고 볼 수 있습니다. 그렇게 MIC가 적용된 운영체제에서 사용자를 항상 같은 레벨의 권한으로만 둘 수 없기 때문에, 권한 승격을 위한 UAC 확인창이 도입된 것입니다. 결국, 우리가 매스컴을 통해서 지겹게 들었던 UAC는 오히려 껍데기에 불과하고 핵심은 바로 MIC라는 것인데요.

따라서, XP와 비스타의 주된 보안 차이는 MIC의 적용에 있습니다. 그렇다면, 현재 사용자 권한을 항상 "high"로 두게 된다면 UAC 확인창이 뜰 이유가 없게 됩니다. 여기서는, 간단하게 사용자 데스크톱 환경을 "high" 레벨로 올려 보는 "실험"을 해보겠습니다.




우선... 어떻게 해야 내가 실행하는 프로그램들이 항상 "high" 권한으로 실행될 수 있을까요? 이 질문에 "탐색기"라고 생각하신 분은 ^^ 제대로 길을 잡으신 것입니다. 그렇죠... 사용자가 실행하는 모든 프로세스들은 탐색기 Shell로부터 실행이 되지요. 만약 "탐색기" 프로세스가 "high" 권한이 된다면, 그로부터 실행되는 모든 프로세스는 그대로 "high" 권한을 적용받게 됩니다. 심지어, 명시적으로 "low"로 적용된 프로세스 조차도 "high" 권한으로 승격되어 실행됩니다.

아래의 그림은, "Process Explorer"를 이용하여 실행 프로세스 목록을 본 것입니다. explorer.exe가 루트에 위치하고 있으며 그 하위에 있는 프로그램들은 모두 탐색기를 통해서 실행된 것을 확인할 수 있습니다.

[그림 1: 탐색기 프로세스]
shell_elevate_admin_1.png

물론 탐색기의 현재 필수 무결성 제어(신뢰도 등급)을 확인해 보면, "medium"으로 되어 있겠고요.

자, 이제 탐색기를 "high" 레벨의 권한으로 실행시켜 볼 텐데요. 방법이 뭐가 있을까요? 음... 시작 메뉴에서 탐색기 아이콘을 오른쪽 버튼으로 눌러서 나오는 "Run as administrator"를 이용해서 실행해 볼까요? 그렇게 되면, "UAC 확인창"이 뜨고 탐색기 인스턴스 하나가 뜨게 됩니다. 어허... 그런데 이게 왠일입니까? "프로세스 탐색기"를 사용하여 다시 확인해 봐도, 위의 "[그림 1: 탐색기 프로세스]"에서 보던 것과 동일한 구조가 유지되어 있고 게다가 "explorer.exe"의 필수 무결성 제어(신뢰도 등급)을 확인해 봐도 여전히 "medium"으로 되어 있는 것을 확인할 수 있습니다.

어쩔 수 없군요. 탐색기가 쉘이니만큼 그 대우가 특별한 것 같습니다. ^^ 음... 그렇다면 .. 어떤 방법을 사용해야 기존 탐색기를 인스턴스를 종료시키고 새롭게 권한이 high로 승격된 탐색기 인스턴스를 띄울 수 있을까요?

그렇죠? ^^ 해답은 "작업 관리자"입니다. 일단, 작업 관리자를 실행시킨 다음에 하단에 있는 "Show processes from all users" 버튼을 누르는 것입니다.

shell_elevate_admin_2.png

UAC 확인창이 뜨고, 이제 "작업 관리자"는 "high" 권한으로 승격되어 실행되어져 있습니다. 그런 다음 프로세스 목록에서 "explorer.exe"를 종료시키고, 다시 "File" / "New Task(Run...)" 메뉴를 실행시켜 explorer.exe를 실행시킵니다.

자,,, 이제 게임은 끝났군요. ^^ 지금 부터 실행되는 모든 프로세스들은 high 권한으로 실행되며 어떠한 UAC 확인 절차도 나타나지 않습니다. 물론, "인터넷 익스플로러 7"을 실행시켜도 예전 XP 시절과 동일하게 웹 브라우저를 보안 제한 없이 사용할 수 있습니다. 이렇게 놓고 조금 써보니... 왠지 불안합니다. XP 쓰던 시절에는 아무런 거리낌없이 사용하던 "Full Trust" 사용자 권한 환경이 비스타를 쓰게 되면서 왠지 이건 아니라는 생각이 들게 되는군요. ^^; 이제 예전처럼 돌리고 싶은데... 아쉽게도 방법이 없습니다. "로그 오프" 한다음에 다시 "로그인" 하십시오. ^^




프로그래머들이 주의해야 할 점.

위의 설명에서는 프로그램과 전혀 관계없는 사용자 동작이었지만, 사실 프로그램으로도 얼마든지 위의 동작이 가능합니다. 작업 관리자를 띄울 필요없이, 위의 동작을 해야 하는 프로세스를 사용자로 하여금 관리자 권한으로 승격시킨 후에, 현재의 탐색기 프로세스 (explorer.exe)를 종료시키고 다시 실행시키면 되기 때문입니다. 물론, 대부분의 프로그래머들은 이런 동작을 (고의가 아닌 이상) 프로그램에 넣을 일이 거의 없겠지만, 탐색기 쉘이나 IE 확장 도구들을 개발하는 분들이라면 위의 글을 읽고 느끼시는 바가 있으실 겁니다.

정리해 보면, 다음과 같은 주의 사항이 요구됩니다.

첫째. 탐색기 쉘이나 IE 확장 도구에서는 "관리자 권한"의 코드가 실행되지 않는다.

MIC는 해당 프로세스가 실행되는 초기에 결정된 후로는 바뀌지 않습니다. 따라서 탐색기등에서 관리 권한을 요구하는 코드를 작성하는 경우, 별도로 대리 프로세스를 두고 그 프로세스를 승격시킨 후 여러분들이 원하는 코드를 실행시켜야 합니다.

둘째. 탐색기 재시작 코드는 반드시 변경하라.

저도 예전에, Shell 관련 플러그 인을 제작할 때 프로그램 설치 이후 그것을 현재의 Shell에 바로 반영하기 위해 explorer.exe를 종료한 후 다시 실행시켰던 적이 있습니다. 이미 기존에 만들어진 프로그램 중에서 이런 식으로 동작되는 프로그램을 부득이하게 설치하게 되었다면 반드시, 명시적으로 "로그오프/로그인"을 하시는 것이 안전하겠고, 새로 만들어질 프로그램들이라면 이를 고려해서 탐색기를 재실행시키기 보다는 사용자로 하여금 다시 로그인을 하도록 유도하는 것이 좋겠습니다. 또는, high로 승격된 상태에서 탐색기를 재실행할 때 반드시 "medium"으로 실행되도록 필수 무결성 제어(신뢰도 등급)을 설정할 수도 있겠습니다.




[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 1/9/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2007-01-13 08시24분
멋지네요 ^_^
songgun
2007-01-15 03시27분
^^ 오랜만입니다.
kevin25
2007-03-22 11시38분
[Loner] 성태씨의 위 글중에 "UAC"는 껍데기 이고 MIC가 핵심이라 지적하셨는데...
제 의견은 좀 다릅니다. UAC는 사용자가 속한 그룹(액세스 토큰 내에서) 중
Administrators나 Backup Operators 와 같은 관리 권한이 있는 경우
이 그룹을 제거하는 것이 UAC이며 MIC는 몇 개의 프로그램 수행 레벨을 지정해 놓고
낮은 수준에서 수행하는 프로그램이 상위 수준의 자원이나 프로세스에 접근을 못하도록 막는 것으로
둘은 서로 다른 기능이라는 거죠.
테스트 하신대로 Task Manager를 관리자 모드로 수행하고 탐색기(explorer.exe)를 수행시키는 것은
분명 수행 수준을 high로 올리는 작업이 맞습니다만, Task manager가 관리자 모드로 수행되는 순간
UAC에 의해 제거된 administrators 그룹 권한이 taskmgr.exe의 액세스 토큰에 포함되기 때문에
UAC가 Off 되는 것 처럼 보이는 거 아닌가요?
high로 수행되었다고 해서 UAC 확인창이 나타나지 않는 것이 아니라
explorer.exe 프로세스가 administrators 그룹을 포함하는 액세스 토큰을 이미 갖고 있기 때문에
UAC 확인 창이 나타나지 않는 듯 싶습니다.
의견 주십시요.
[guest]
2007-12-31 06시39분
유수석님 말씀이 맞습니다. 솔직히 "껍데기"는 너무 심한 표현 같습니다.

그렇긴 해도, (순전히 제 개인적인 생각으로) MIC가 근간이 되어 UAC가 나왔다는 의견에는 변함이 없습니다. 왜냐하면, UAC의 기준이 되는 관리자 성격의 작업들이 결국 MIC 단에서의 Medium과 High를 구분하는 기준과 다를 바 없기 때문입니다. 이미 MIC 구현 단계에서부터 Admin과 제한된 사용자 계정은 구분이 지어졌을 뿐이고, 그것을 어떻게 하면 매끄럽게 (현재의 XP 시스템에 반하지 않고) 붙일 수 있느냐는 고민에서 UAC 기능이 구현되어졌을 거라고 봅니다. 기능 자체에서는 근간이 아니라 해도, 개념은 이미 근간이었다는 의미로 받아주시면 좋을 것 같습니다. ^^ (그나저나,,, 이를 뒷받침할 근거는 없고,,, 오히려 그 반대일 수도 있겠습니다.)

사실 UIPI 같은 것도,,, 결국 MIC를 바탕으로 하기 때문에. ^^
kevin25

1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13893정성태2/27/20252225Linux: 115. eBPF (bpf2go) - ARRAY / HASH map 기본 사용법
13892정성태2/24/20252983닷넷: 2325. C# - PowerShell과 연동하는 방법파일 다운로드1
13891정성태2/23/20252500닷넷: 2324. C# - 프로세스의 성능 카운터용 인스턴스 이름을 구하는 방법파일 다운로드1
13890정성태2/21/20252329닷넷: 2323. C# - 프로세스 메모리 중 Private Working Set 크기를 구하는 방법(Win32 API)파일 다운로드1
13889정성태2/20/20253054닷넷: 2322. C# - 프로세스 메모리 중 Private Working Set 크기를 구하는 방법(성능 카운터, WMI) [1]파일 다운로드1
13888정성태2/17/20252498닷넷: 2321. Blazor에서 발생할 수 있는 async void 메서드의 부작용
13887정성태2/17/20253074닷넷: 2320. Blazor의 razor 페이지에서 code-behind 파일로 코드를 분리 및 DI 사용법
13886정성태2/15/20252574VS.NET IDE: 196. Visual Studio - Code-behind처럼 cs 파일을 그룹핑하는 방법
13885정성태2/14/20253236닷넷: 2319. ASP.NET Core Web API / Razor 페이지에서 발생할 수 있는 async void 메서드의 부작용
13884정성태2/13/20253523닷넷: 2318. C# - (async Task가 아닌) async void 사용 시의 부작용파일 다운로드1
13883정성태2/12/20253268닷넷: 2317. C# - Memory Mapped I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13882정성태2/10/20252581스크립트: 70. 파이썬 - oracledb 패키지 연동 시 Thin / Thick 모드
13881정성태2/7/20252832닷넷: 2316. C# - Port I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13880정성태2/5/20253172오류 유형: 947. sshd - Failed to start OpenSSH server daemon.
13879정성태2/5/20253407오류 유형: 946. Ubuntu - N: Updating from such a repository can't be done securely, and is therefore disabled by default.
13878정성태2/3/20253198오류 유형: 945. Windows - 최대 절전 모드 시 DRIVER_POWER_STATE_FAILURE 발생 (pacer.sys)
13877정성태1/25/20253249닷넷: 2315. C# - PCI 장치 열거 (레지스트리, SetupAPI)파일 다운로드1
13876정성태1/25/20253709닷넷: 2314. C# - ProcessStartInfo 타입의 Arguments와 ArgumentList파일 다운로드1
13875정성태1/24/20253137스크립트: 69. 파이썬 - multiprocessing 패키지의 spawn 모드로 동작하는 uvicorn의 workers
13874정성태1/24/20253558스크립트: 68. 파이썬 - multiprocessing Pool의 기본 프로세스 시작 모드(spawn, fork)
13873정성태1/23/20252983디버깅 기술: 217. WinDbg - PCI 장치 열거파일 다운로드1
13872정성태1/23/20252885오류 유형: 944. WinDbg - 원격 커널 디버깅이 연결은 되지만 Break (Ctrl + Break) 키를 눌러도 멈추지 않는 현상
13871정성태1/22/20253292Windows: 278. Windows - 윈도우를 다른 모니터 화면으로 이동시키는 단축키 (Window + Shift + 화살표)
13870정성태1/18/20253732개발 환경 구성: 741. WinDbg - 네트워크 커널 디버깅이 가능한 NIC 카드 지원 확대
13869정성태1/18/20253456개발 환경 구성: 740. WinDbg - _NT_SYMBOL_PATH 환경 변수에 설정한 경로로 심벌 파일을 다운로드하지 않는 경우
13868정성태1/17/20253112Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...