20160512

1. 동시성 프로그램의 이해
2. Access Pattern based Detection
access pattern based detection
1) Read – Write – Read 패턴: 같은 값을 읽어야 하는데, 중간에 write 연산이 끼어듦으로 인해 달라짐.
2) Write – Write – Read 패턴: 쓴 값을 읽어야 하는데, 다른 값을 읽게 됨.
3) Write – Read – Write 패턴: 쓰기가 끝나기 전에 읽기가 발생
4) Read – Write – Write 패턴: check-and-set 과정 도중에 write가 발생함.

3. Happens-before Relation based Atomicity Bug Detection
– Velodrome은 happens-before 관계 기반의 atomicity bug detection 기법이다. 트랜잭션 사이의 happens-before 관계를 본다. Happens-before 관계가 cyclic하다면 non-serializable하고, 따라서 atomicity bug가 있다. Intuition을 이해하는 것이 중요하다. Atomic code block끼리는 interleaving하면 안 된다는 점에 착안 (중요!).
– An execution is a sequence of operations
– A transaction in an execution is the sequence of operations in a thread, that correspond to an execution of an atomic block
– An execution is serial if each transaction’s operation execute contiguously, without interleaving
– An execution is serializable if and only if the transactional happens-before relation (⋖) is acyclic
happens-before in transactions 2.PNG
happens-before in transactions 3.PNG
– 다음 예제는 transaction 사이에 cycle이 발생해서 atomicity가 깨지는 경우.
Velodrome example.PNG
– Velodrome은 false positive가 있다. Read 없이 write만으로 이루어지면 transaction 사이의 happens-before 관계가 cyclic해도 결과에 영향을 주지 않음.

false positive of Velodrome.PNG

– 지금까지는 프로그램을 실행해보고 concurrency bug가 발생하는지 확인함. 하지만 이렇게 실행하고 테스팅하는 과정에서 false positive, false negative가 발생할 수 있음. 이러한 것을 해결하고자 실행을 동적으로 조절하고자 하는 것이 CalFuzzer이다. CalFuzzer는 machine instruction에 probe를 삽입하며, 각 probe에서 사용자의 정의에 따라 원하는 동작을 할 수 있음.

CalFuzzer Framework.PNG

– CalFuzzer는 target Java 바이트 코드에 probe를 삽입해, 특정 이벤트 이전 또는 이후에 실행되도록 할 수 있다. Dynamic analysis 단계에서는 probe를 사용해 실행 시간 중의 정보 추출하며, 테스팅 단계에서는 probe를 사용해 일정 순서에 따라 쓰레드를 실행하도록 할 수 있다.
– Probe를 삽입할 수 있는 위치는 다음과 같다.
bytecode instrumentation probes.PNG

– CalFuzzer는 Soot을 사용해서 bytecode instrumentation을 수행한다. Soot은 bytecode를 Jimple code로 변환한다. Jimple은 Soot에서 사용하는 intermediate representation이다. Jimple code는 bytecode보다 분석하고 instrument하기 쉽다. CalFuzzer는 target byte code를 Soot을 사용해 Jimple code로 변환한 다음, Jimple code에 probe 코드를 추가한다. 그 다음에 Jimple code를 bytecode로 변환한다. 아주 드문 경우에 원래 코드의 의미가 달라지기도 한다.

dynamic analysis phase.PNG

– javato.activetesting.analysis.Observer.getIidToLine(iid) 사용하면 소스 코드 위치를 확인할 수 있다.
– volatile의 경우 대부분 무시하면 된다.


2. Docker
Docker는 container 기술을 사용해 경량의 가상 환경을 만들어준다. Docker는 리눅스 환경 전체를 이미지로 관리할 수 있게 해준다. Docker 이미지는 커널을 포함하지 않으며, 호스트 시스템의 커널을 사용한다. 따라서 경량으로 이미지를 관리할 수 있을 뿐 아니라, 성능 오버헤드도 없다. 기존의 가상화 환경에서는 호스트 시스템과 게스트 시스템의 커널이 모두 있었지만, Docker 시스템에서는 호스트 커널만 있기 때문이다. 흔히 “Docker는 이미지를 실행한다”고 표현하지만, 실제로는 단순히 논리적으로 분리하는 것에 그치는 것으로 보인다. 격리라는 단어도 실제 Docker의 동작에 비하면 과한 것 같다.
Container 기술이 주목받는 것에는 크게 두 가지 이유가 있는 것으로 보인다. 첫째로, 개발 환경의 다양화이다. 어플리케이션에 따라 필요한 라이브러리와 도구들이 달라짐에 따라, 이를 관리하는 것이 어렵게 되었다. 어플리케이션 개발은 개발자의 컴퓨터에서 한다 하더라도, 배포가 어렵다. 사용 환경을 container 이미지로 만들어둔다면 배포하는 것이 훨씬 편하다. 이미지 크기가 작기 때문에 배포도 어렵지 않을 것으로 보인다. 두 번째로, 경량으로 가상 환경을 제공할 수 있다는 점이다. 흔히 사용되는 가상화 기술은 hypervisor를 사용해 가상 환경을 구축한다. 이 때문에 가상화 환경은 많은 성능 손실을 유발한다. 호스트 시스템과 게스트 시스템이 이중으로 실행되기 때문이다. 게스트 시스템은 게스트 자체의 운영체제와 커널을 갖기 때문에 가상 머신 이미지의 크기도 크다.
Docker, 또는 container 기술의 보안 문제를 보고 있는데, 문제가 있는 것 같기도 하고, 없는 것 같기도 하다. 지금으로서 보이는 가장 큰 문제는 container들이 호스트 시스템의 커널을 공유한다는 점이다. 커널을 공유함으로 인해 경량 가상화가 이루어지긴 하지만, 이 때문에 오히려 더 취약해진 점이 있다. 호스트 시스템이 공격당해 신뢰할 수 없게 되면, 해당 시스템의 모든 container들이 아주 쉽게 공격당하기 때문이다. 기존의 가상화 기술에 비하면 container의 파일 시스템은 아주 쉽게 접근할 수 있다. 관리자는 docker의 파일 시스템을 /var/lib/docker/devicemapper/mnt/*/rootfs 경로로 접근 가능하다. Docker의 프로세스 또한 일반 프로세스로 실행되기 때문에, 공격자가 루트 권한을 얻는다면 어렵지 않게 조작할 수 있을 것으로 보인다. 한편으로는 리눅스 커널 보안이라는 측면에서는 기존의 보안 측면과 크게 다르지 않은 것 같다. 그리고 더 중요한 것은, docker와 hypervisor 기반의 가상화가 반드시 exclusive하게 사용될 필요는 없다는 점이다(http://devops.com/2014/11/24/docker-vs-vms/). Docker의 두 가지 장점 중에 첫 번째 장점만 살리는 것이다. 가상 머신에서 실행함으로써 조금이나마 관리자의 임의 접근 가능성을 낮출 수 있을지도 모른다. 실제로 대부분의 사용자는 제3의 서비스 제공자로부터 단순히 Docker 서비스만을 받지는 않을 것으로 보인다. 관리자가 마음만 먹으면 파일 시스템을 열어볼 수 있다는 것은 매우 위험하다. 그래도 Docker의 보안성을 높이기 위한 시도는 필요한가? 필요한 것 같기도 하다. Hypervisor 없이도 경량 가상화를 이룰 수 있다는 것은 아주 좋은 선택지인 것 같기도 하다.
찾아보니 Docker를 위한 security solution들이 어느 정도는 있다. 생각해보면 security solution이 없는 것이 이상하기도 하다. Container 환경이 되면 더 많은 보안 위협에 쉽게 노출되기 때문이다. 아마 찾아보면 더 많은 security solution이 있을 것으로 보인다. 우선 찾은 것은 Vormetric 에서 만든 security solution이다. 호스트 시스템의 운영체제 레이어에서 암호화, 접근 제어, 로깅 등을 하겠다는 것이다.

Docker 보안에 대한 유익하고 재미있는 링크들. Boycott docker가 개인적으로는 가장 재미있었다.
[1] New DockerCon video: Docker Security (renamed from Docker and SELinux), https://blog.docker.com/2014/07/new-dockercon-video-docker-security-renamed-from-docker-and-selinux/
[2] Daniel J Walsh, Are Docker containers really secure?, https://opensource.com/business/14/7/docker-security-selinux
[3] Daniel J Walsh, Bringing new security features to Docker, https://opensource.com/business/14/9/security-for-docker
[4] Daniel J Walsh, Docker security in the future, https://opensource.com/business/15/3/docker-security-future
[5] hardware assisted docker containers, https://news.ycombinator.com/item?id=8559322
[6] boycott docker, http://www.boycottdocker.org/

Advertisements
Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in 1) Memo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

누적 방문자 수
  • 88,257 hits
%d bloggers like this: