Microsoft MVP성태의 닷넷 이야기
Windows: 15. MIC 환경 구성 - Windows XP와 유사한 보안 설정 [링크 복사], [링크+제목 복사],
조회: 23314
글쓴 사람
정성태 (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

... 31  32  33  [34]  35  36  37  38  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
13089정성태6/28/202215078개발 환경 구성: 646. HOSTS 파일 변경 시 Edge 브라우저에 반영하는 방법
13088정성태6/27/202213501개발 환경 구성: 645. "Developer Command Prompt for VS 2022" 명령행 환경의 폰트를 바꾸는 방법
13087정성태6/23/202217487스크립트: 41. 파이썬 - FastAPI / uvicorn 호스팅 환경에서 asyncio 사용하는 방법 [1]
13086정성태6/22/202216891.NET Framework: 2026. C# 11 - 문자열 보간 개선 2가지파일 다운로드1
13085정성태6/22/202216661.NET Framework: 2025. C# 11 - 원시 문자열 리터럴(raw string literals)파일 다운로드1
13084정성태6/21/202215440개발 환경 구성: 644. Windows - 파이썬 2.7을 msi 설치 없이 구성하는 방법
13083정성태6/20/202216044.NET Framework: 2024. .NET 7에 도입된 GC의 메모리 해제에 대한 segment와 region의 차이점 [2]
13082정성태6/19/202215106.NET Framework: 2023. C# - Process의 I/O 사용량을 보여주는 GetProcessIoCounters Win32 API파일 다운로드1
13081정성태6/17/202214252.NET Framework: 2022. C# - .NET 7 Preview 5 신규 기능 - System.IO.Stream ReadExactly / ReadAtLeast파일 다운로드1
13080정성태6/17/202215236개발 환경 구성: 643. Visual Studio 2022 17.2 버전에서 C# 11 또는 .NET 7.0 preview 적용
13079정성태6/17/202212682오류 유형: 814. 파이썬 - Error: The file/path provided (...) does not appear to exist
13078정성태6/16/202215834.NET Framework: 2021. WPF - UI Thread와 Render Thread파일 다운로드1
13077정성태6/15/202216850스크립트: 40. 파이썬 - PostgreSQL 환경 구성
13075정성태6/15/202213691Linux: 50. Linux - apt와 apt-get의 차이 [2]
13074정성태6/13/202214720.NET Framework: 2020. C# - NTFS 파일에 사용자 정의 속성값 추가하는 방법파일 다운로드1
13073정성태6/12/202214814Windows: 207. Windows Server 2022에 도입된 WSL 2
13072정성태6/10/202215047Linux: 49. Linux - ls 명령어로 출력되는 디렉터리 색상 변경 방법
13071정성태6/9/202215702스크립트: 39. Python에서 cx_Oracle 환경 구성
13070정성태6/8/202216389오류 유형: 813. Windows 11에서 입력 포커스가 바뀌는 문제 [1]
13069정성태5/26/202218374.NET Framework: 2019. C# - .NET에서 제공하는 3가지 Timer 비교 [2]
13068정성태5/24/202217040.NET Framework: 2018. C# - 일정 크기를 할당하는 동안 GC를 (가능한) 멈추는 방법 [1]파일 다운로드1
13067정성태5/23/202215150Windows: 206. Outlook - 1년 이상 지난 메일이 기본적으로 안 보이는 문제
13066정성태5/23/202214627Windows: 205. Windows 11 - Windows + S(또는 Q)로 뜨는 작업 표시줄의 검색 바가 동작하지 않는 경우
13065정성태5/20/202215857.NET Framework: 2017. C# - Windows I/O Ring 소개 [2]파일 다운로드1
13064정성태5/18/202215226.NET Framework: 2016. C# - JIT 컴파일러의 인라인 메서드 처리 유무
13063정성태5/18/202215617.NET Framework: 2015. C# - 인라인 메서드(inline methods)
... 31  32  33  [34]  35  36  37  38  39  40  41  42  43  44  45  ...