저자: 코리 미니야드, 몬타비스타 소프트웨어
제1장: 고객 사례에 대한 첫 접촉
MontaVista는 고객으로부터 네트워크 어플라이언스용 SELinux 정책 생성 요청을 받았습니다. 고객은 자사 고객들이 어플라이언스에서 애플리케이션을 실행할 수 있는 기능을 추가하는 작업을 진행 중이었으며, 어플라이언스에서 실행되는 컨테이너와 관리 시스템 간의 모든 방향에서 최대한 엄격한 격리를 원했습니다. 이러한 애플리케이션은 보안에 매우 민감하여 관리 시스템이 손상될 경우 관리 시스템 자체로부터 보호되어야 하고, 다른 컨테이너로부터도 보호되어야 하며, 동시에 관리 시스템 또한 컨테이너로부터 보호되어야 했습니다.
이전에 다른 고객사를 위해 SELinux 정책을 구축한 경험이 있어서 이번에도 크게 어렵지 않을 거라고 생각했습니다. 하지만 완전히 틀렸습니다! 이전 사례는 디스크가 있는 일반적인 서버 구성의 대규모 시스템이었던 반면, 이번 시스템은 디스크가 전혀 없고 RAM에서만 작동하는 고도로 임베디드 시스템이었습니다. 이 시스템의 커널은 내장된 CPIO 아카이브를 사용하여 부팅되고, 커널은 이 아카이브를 압축 해제하여 루트 파일 시스템에 접근합니다.
업무에 몰두하기
SELinux는 개념적으로는 간단하지만, 처음부터 실제로 구현하는 것은 엄청나게 복잡합니다. 대부분의 복잡성은 표준 정책에 가려져 있는 경우가 많습니다. 우선 lxc를 컨테이너 환경에서 작동시키고, 대상 시스템에서 SELinux 소프트웨어를 활성화하고, 참조 정책을 설정하는 작업부터 시작했습니다. 컨테이너 관련 경험이 풍부했기 때문에 컨테이너 작업은 빠르게 진행되었습니다. 하지만 SELinux 소프트웨어는 다소 어려웠습니다. Busybox, lxc, PAM 등 여러 애플리케이션과 커널이 SELinux를 활성화하고 있었기 때문에 제대로 빌드하려면 몇 가지 작업이 필요했습니다. 특히 PAM은 골칫거리였습니다. PAM을 컴파일해야 SELinux도 컴파일할 수 있었는데, PAM은 SELinux를 활성화하고 있었기 때문에 SELinux 컴파일 후 SELinux 기능을 적용하려면 다시 컴파일해야 했습니다. 다행히 이러한 유형의 문제를 다뤄본 경험이 있었기 때문에 크게 어렵지는 않았습니다.
참조 정책은 그다지 잘 진행되지 않았습니다. 첫 번째 주요 문제는 램디스크에서 실행하는 것이었습니다. 고객이 사용하던 RAM 블록 장치는 확장 속성을 지원하지 않아 파일에 SELinux 컨텍스트를 추가할 수 없었기 때문에 tmpfs로 전환해야 했습니다. 다행히 tmpfs는 이를 지원합니다.
tmpfs를 실행한 후 참조 정책 작업을 시작했습니다. 그런데 그 정책 크기가 너무 커서 고객 시스템에는 적합하지 않았습니다. 게다가 tmpfs 환경에서 작업하는 동안 cpio는 확장 속성을 저장할 방법이 없었기 때문에 모든 파일의 보안 컨텍스트를 매번 복원해야 했습니다. 참조 정책을 시스템에 설치하는 데는 성공했지만, 파일 보안 컨텍스트를 복원하는 데 40초나 걸렸습니다. 도저히 용납할 수 없는 시간이었습니다.
안타깝게도, 처음부터 완전한 정책을 작성하려면 일정이 크게 지연될 것입니다. SELinux 보안 정책은 기본 기능만 작동시키더라도 고려해야 할 사항이 너무 많습니다. 게다가, 그 정책을 유지 관리하는 데에도 많은 시간과 노력이 필요할 것입니다. 기본 부분을 오픈 소스로 공개하는 것은 좋은 방법일 수 있지만, 보안 정책 유지 관리는 저희 전문 분야가 아니며, 상당한 시간이 소요될 것입니다. 이전에 이런 시도를 한 사람은 아무도 없었던 것 같습니다. 하지만…
OpenWRT를 입력하세요
다행히도, OpenWRT 그룹이 자사 배포판용 SELinux 정책을 개발 중이라는 사실을 알게 되었습니다. 기본적인 작업은 완료되었고, 주로 애플리케이션 지원 작업을 진행하고 있었습니다. 마치 하늘이 내려준 선물 같았습니다. 우리가 필요로 하는 것과 훨씬 더 비슷했고, 크기도 훨씬 작았으며, 임베디드 시스템에서 예상되는 기능들을 지원했습니다.
하지만 완벽하지는 않았습니다. SELinux 개발자들이 결국 모든 것에 적용할 예정이었던 새로운 정책 언어인 CIL로 작성되었기 때문입니다. 무엇보다도, 우리에게는 생소한 언어였습니다. 기본적인 개념은 통용될 수 있었지만, 사용 방식은 상당히 달랐습니다. 게다가 CIL을 아는 것(기존 커널 정책 언어를 아는 것과 마찬가지로)만으로는 충분하지 않았습니다. 정책을 작성자들이 시스템을 어떻게 구현했는지 알아야만 이를 활용하고 확장할 수 있었습니다.
공부하고 배우는 데 많은 시간이 걸렸습니다. 관련 문서가 부족해서 대부분 리버스 엔지니어링을 해야 했습니다. OpenWRT는 대부분의 배포판이 /var에 저장하는 내용을 /tmp에 저장하는데, 우리가 사용하던 배포판은 일반적인 배포판이었습니다. 또한 OpenWRT는 squashfs를 사용하기 때문에 tmpfs가 제대로 작동하지 않았습니다. 하지만 이러한 문제들은 해결할 수 있었습니다. 파일 컨텍스트는 약 1초 만에 복원할 수 있었고, 다른 문제들도 해결하는 데 그리 오래 걸리지 않았습니다. 물론 배우는 데 시간이 걸렸지만, 그렇게 힘들지는 않았습니다.
보안을 위한 디자인
이제 아주 자세한 부분으로 들어가 보겠습니다. 고객은 이미 시스템에 대해 철저히 검토했고 기본적인 보안 설계를 잘 갖추고 있었습니다. 하지만 그럼에도 불구하고, 보안 정책을 함께 수립하는 과정에서 소프트웨어에 잠재적인 보안 문제가 될 수 있는 부분을 발견했습니다. 정책으로 처리하는 대신, 프로그램 자체에서 문제를 해결했습니다.
SELinux를 사용하려면 중요한 데이터를 최적으로 보호하고 침입 발생 시 시스템을 안전하게 지키기 위해 시스템을 구획화하는 방안을 고려해야 합니다. 이는 매우 중요합니다. 제대로 설계되지 않은 시스템은 SELinux의 이점을 제대로 누리지 못할 뿐 아니라, 오히려 가장 취약한 시스템이 되기 때문입니다.
다음 블로그 게시물도 기대해주세요!
MVSecure 서비스 및 MVXpert 서비스 에 대해 자세히 알아보세요.
Please reach out to discuss your particular scenario today.
