.NET CLR4 보안 모델 - 3. CLR4 보안 모델에서의 APTCA 역할
지난 2개의 글에서,
.NET CLR4 보안 모델 - 1. "Security Level 2"란?
; https://www.sysnet.pe.kr/2/0/1680
.NET CLR4 보안 모델 - 2. 샌드박스(Sandbox)을 이용한 보안
; https://www.sysnet.pe.kr/2/0/1681
혹시 이상한 점이 없었나요? ^^
예를 들어, "[assembly: SecurityTransparent]" 특성이 적용된 경우 그 이후로는 모든 코드들이 "SecurityTransparent"에 속한다고 해놓고선,,, 어떻게 FileStream 생성자와 그것의 Handle 속성은 SecuritySafeCritical, SecurityCritical로 부여한 특성이 동작한 걸까요?
마이크로소프트의 DLL들만 특별한 대우를 받는 걸까요? 물론 아닙니다. 여기에 바로 APTCA(AllowPartiallyTrustedCallers) 특성의 비밀이 있습니다. ^^
다소 혼란스러운 점이 있다면, CLR2에서부터 지원된 APTCA 특성이었는데,
.NET CLR2 보안 모델에서의 APTCA 역할
; https://www.sysnet.pe.kr/2/0/1679
CLR4에서는 같은 특성임에도 불구하고 약간 그 역할이 바뀌었다는 것입니다. 어떻게 바뀌었는지... 테스트를 한번 해볼까요? ^^
사실, 기존 2개의 글("
.NET CLR4 보안 모델 - 1. "Security Level 2"란?", "
.NET CLR4 보안 모델 - 2. 샌드박스(Sandbox)을 이용한 보안")에 보면 이상한 점이 하나 더 있긴 합니다.
"[assembly: SecurityTransparent]" 특성이 적용된 경우 (또는, 샌드박싱내에서 실행된 경우), 할 수 있는 일이 거의 없다는 것입니다. 산술 계산하는 plug-in 정도라면 모를까, 막상 프로그래밍하다 보면 많은 코드들이 SecurityCritical로 분류되어 있기 때문에 가능한 작업이 많지 않다는 문제가 있습니다.
바로 이런 제약을 해결하기 위해 APTCA에 특별한 능력이 부여됩니다. CLR2에서는 GAC에 등록된 어셈블리에 APTCA 특성이 있는 경우 해당 DLL을 "Partial Trust"에서 활성화된 코드들이 이용할 수 있었습니다. 하지만 CLR4에서는 SecuritySafeCritical, SecurityCritical 특성을 적용해 세밀한 보안 제어를 할 수 있도록 바뀌게 됩니다.
실제로 어떻게 적용되는지 예제와 함께 설명할 텐데요. 처음부터 다시 작성하지 않고, "
.NET CLR4 보안 모델 - 1. "Security Level 2"란?" 글의 예제를 확장해 보겠습니다.
- HostApp (콘솔 프로젝트: 우리가 만드는 응용 프로그램)
- LoadLib (라이브러리 프로젝트: 3rd-party 라이브러리를 로드해서 그 기능을 호출하는 클래스를 정의)
- UntrustedLib (라이브러리 프로젝트: 3rd-party에서 제작한 라이브러리라고 가정)
위와 같은 프로젝트 구성에서는 UntrustedLib 프로젝트에서 FileStream.Handle 속성을 접근할 때 보안 오류가 발생하는 문제가 있었습니다. 우리가 지금 원하는 것은, plug-in 측에서 FileStream.Handle 접근이 꼭 필요하기 때문에 그것에 대해서만 허용하는 방법입니다.
이를 위해 "HostService" 라이브러리 프로젝트를 하나 더 생성하고 서명한 후 다음과 같은 코드를 추가해 줍니다.
using System.Security;
using System.IO;
[assembly: AllowPartiallyTrustedCallers]
public class SecurityService
{
[SecuritySafeCritical]
public static long GetFileHandle(FileStream fs)
{
return fs.Handle.ToInt64();
}
}
보시는 바와 같이, APTCA 설정을 했고 SecurityTransparent 코드에서 호출 가능하도록 SecuritySafeCritical에 속하는 GetFileHandle 메서드를 구현했습니다. (GAC에 등록할 필요는 없습니다.)
이제 (외부 업체에서 작성했다고 가정한) UntrustedLib 프로젝트에 HostService 라이브러리 프로젝트를 참조 추가하고 코드를 변경해 줍니다.
using System;
using System.IO;
using System.Security;
[assembly: SecurityTransparent]
namespace UntrustedLib
{
public class PlugInExtension
{
// ... [생략: NormalMethod]...
public void AccessCritical()
{
try
{
using (FileStream file = new FileStream(@".\test.dat", FileMode.Create, FileAccess.ReadWrite, FileShare.ReadWrite))
{
long fileHandle = SecurityService.GetFileHandle(file);
Console.WriteLine(fileHandle.ToString());
}
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
}
}
}
실행해 보면, 전에는 FileStream.Handle 값을 읽는 과정에서 보안 오류가 발생했지만 이제는 깨끗하게 실행되는 것을 볼 수 있습니다. 왜냐하면 [SecurityTransparent]AccessCritical 코드에서 [SecuritySafeCritical]GetFileHandle 코드를 경유해 [SecurityCritical]get_Handle을 접근했기 때문입니다.
(
위의 테스트 코드는 Net40Sec2.zip 첨부파일에 포함시켰습니다.)
그런데... 잠깐만요. 저게 보안 맞습니까? 그럼, 외부 업체에서 plug-in과 함께 APTCA가 적용된 어셈블리를 함께 제공할수만 있다면 스스로 보안을 위배할 수 있는 코드를 자유롭게 만들 수 있는 거 아닙니까?
맞습니다. ^^
그래서 사실 "[assembly: SecurityTransparent]" 특성이 적용된 경우는 모든 프로젝트를 호스트 시스템을 개발하는 측에서 제어할 수 있는 경우 보안 제어를 명시하는 용도로만 사용할 수 있습니다. "
What's New in Code Access Security in .NET Framework 4.0 - Part I" 글에서도 이 때문에 "This is all fine if we’re only working with our own code" 라는 단서를 달고 있습니다.
만약 "[assembly: SecurityTransparent]" 특성을 이용해 보안을 제어하고 싶다면, 반드시 외부 업체의 DLL은 한 개만 로드한다는 제약을 가하거나, 아니면 다중으로 로드할 수 있는 경우엔 대상 DLL을 로드하기 전에 .NET Reflection 등으로 DLL 측에 APTCA 특성이 있는지 검사하는 코드를 넣어두어야 합니다.
이런 부가적인 코드 설정이 마음에 들지 않는다면 샌드 박싱을 이용한 보안 처리로 넘어가야 합니다.
예제 코드를 위해 "
.NET CLR4 보안 모델 - 2. 샌드박스(Sandbox)을 이용한 보안"의 것을 확장해 보겠습니다.
- TestApp (호스트 프로그램 용 콘솔 프로젝트 - 샌드박스를 생성)
- TestLib (외부 업체에서 만들어졌다고 가정하는 plug-in 라이브러리 프로젝트)
이 상태에서 이미 만들어 두었던 HostService 라이브러리 프로젝트를 추가하고, 마찬가지로 TestLib 프로젝트에서 HostService 프로젝트를 참조한 후, Class1.DoCriticalMethod의 코드도 다음과 같이 변경해 줍니다.
using System;
using System.IO;
public class Class1
{
// 생략: DoMethod
public static void DoCriticalMethod()
{
try
{
using (FileStream file = new FileStream(@".\test.dat", FileMode.Create, FileAccess.ReadWrite, FileShare.ReadWrite))
{
long handle = SecurityService.GetFileHandle(file);
Console.WriteLine(handle.ToString());
}
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
}
}
이 단계에서 실행해 보면 어떻게 될까요? "[assembly: SecurityTransparent]" 특성만 적용했던 (샌드박싱을 이용하지 않은) 이전의 예제와는 달리 여전히 다음과 같은 예외가 발생하는 것을 확인할 수 있습니다.
System.MethodAccessException: Attempt by security transparent method 'SecurityService.GetFileHandle(System.IO.FileStream)' to access security critical method 'System.IO.FileStream.get_Handle()' failed.
Assembly 'HostService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2a9ed378705e40fd' is partially trusted, which causes the CLR to make it entirely security transparent regardless of any transparency annotations in the assembly itself.
In order to access security critical code, this assembly must be fully trusted.
at SecurityService.GetFileHandle(FileStream fs)
at Class1.DoCriticalMethod()
그렇습니다. 샌드 박스 모델에서는 단순히 APTCA를 적용한 어셈블리를 경유했다고 해서 CLR4의 보안 모델을 우회할 수는 없습니다. 그럼 어떻게 해야 할까요?
바로, GAC에 HostService.dll을 등록해야만 합니다. 등록한 이후에는 오류 없이 정상적으로 예제 코드가 실행됩니다.
자!!! 이 정도면... 보안 측면에서 아무런 문제가 없습니다. GAC에 등록하기 위해서는 (윈도우의) 관리자 권한을 요구하므로 외부 업체에서 배포하는 DLL 내의 코드에서 우회할 수는 없습니다.
(
위의 테스트 코드는 TestApp2.zip 첨부파일에 포함시켰습니다.)
이제까지의 글을 읽고 나면 다음의 글을 쉽게 이해할 수 있습니다. ^^
Migrating an APTCA Assembly to the .NET Framework 4
; https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/march/clr-inside-out-migrating-an-aptca-assembly-to-the-net-framework-4
휴~~~ 어쨌든 이것으로 CLR4의 보안 모델을 정리하는 글이 끝나는 군요. 언제 시간 내서 쓰겠다고 벼르기만 하다가... 지금이라도 정리하니 속이 다 후련합니다. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]