바쿠스 2018 11월 세미나 발표자료

1. LINUX SECURITY
In respect of isolation

2. 가상 사례를 생각해봅시다
◦ 초보 시스템 관리자 박구수씨

3. 가상 사례를 생각해봅시다

4. 가상 사례를 생각해봅시다

5. 가상 사례를 생각해봅시다

6. 가상 사례를 생각해봅시다

7. 가상 사례를 생각해봅시다
◦ 며칠 뒤

8. 가상 사례를 생각해봅시다

9. 가상 사례를 생각해봅시다

10. 가상 사례를 생각해봅시다

11. 무엇이 문제였을까요?
◦ 보안 업데이트를 제 때 하지 않았습니다

12. 하지만…
◦ 보안 업데이트만을 열심히 하면 항상 안전할까요?
◦ 모든 취약점을 사전에 알고 막을 수 없으니,
취약점이 있더라도 피해를 최소화할 방안이 필요합니다.

13. user를 사용한 구분
◦ 각 서비스를 위한 사용자를 만들어 서로 다른 사용자로 실행합니다
◦ Uid 0, root는 사용하지 않습니다

14. 실제 서버의 예시 - mimosa

15. Linux access control

16. Linux access control
◦ 각 파일/폴더는 소유자, 그룹을 가지며,
Owner, Group, Others로 구분된 접근 권한
이 설정됩니다.

17. Linux access control
◦ 각 프로세스는 특정한 사용자의 권한으로
실행됩니다.

18. Inside of Linux access control
◦ OS를 수강할 계획이 있는 분은 알아두시면 좋습니다!
◦ 각 프로세스는 ruid, euid, suid를 갖습니다.
◦ ruid: real user ID
-> 프로그램을 실제로 실행한 유저의 uid
◦ euid: effective user ID
-> 실행한 유저의 uid와 프로세스의 uid가 다를 경우
◦ suid: saved set-user-ID
-> 저장된 user ID

19. Inside of Linux access control
◦ 프로세스는 시스템콜을 사용하여 uid를 바
꿀 수 있습니다.
◦ 시스템콜: setuid, seteuid, setresuid 등…
◦ 규칙 1
프로세스의 uid가 0(root)인 경우, 임의의
uid로 바꿀 수 있습니다.
◦ 규칙 2
그 외의 경우, ruid, euid, suid의 값 중 하나
로만 바꿀 수 있습니다.

20. Inside of Linux access control
◦ suid의 사용처
◦ Uid 0로 돌던 프로그램이 잠시 다른 사용자
로서 작업 후 되돌아 오기 위해 사용됩니다.

21. Inside of Linux access control
◦ 모든 프로세스에게 suid 0를 줄 수는 없습니다.
◦ 그러면 root의 권한이 필요한 경우는 어떻게 해야 할까요?

22. Inside of Linux access control

23. Privilege elevation example
◦ /etc/shadow: 모든 사용자의 비밀번호가 저
장되는 파일
◦ 아무나 볼 수 있어서는 안됩니다.
◦ 다른 사용자의 비밀번호를 수정할 수 있어
서는 안됩니다.
◦ 하지만, 자신의 비밀번호를 수정할 수 있어
야 합니다.

24. setuid bit의 등장
◦ 3자리 8진수였던 mod가 4자리로 확장됩니
다.
◦ setuid bit이 활성된 프로그램의 경우, 해당
프로그램의 owner의 uid를 euid로 갖고 프
로그램이 실행됩니다!
◦ 아까 본 setuid 시스템콜과 이름은 같으나
다른 녀석입니다.

25. Privilege elevation example

26. Privilege elevation example
◦ setuid bit이 설정된 프로그램은 owner가 허가할 수 있는 방식으로만 작동해야 합니다.
◦ passwd -> 프로그램을 실행한 user의 비밀번호만을 변경
◦ sudo -> 프로그램을 실행한 user가 sudoers에 들어있고, 자신의 비밀번호를 옳게 입력한 경우에
만 권한 상승
◦ su -> 다른 사용자의 비밀번호를 옳게 입력한 경우에만 해당 사용자로 uid 변경

27. 번외편) mod의 4번째 자리
◦ 4 -> setuid bit
◦ 2 -> setgid bit
setuid bit과 유사하게, 프로그램의 group으로서 실행되도록 합니다.
◦ 1 -> sticky bit

28. 번외편) sticky bit
◦ Others에게 read, write, execution 권한을 모두 주는 경우에 사용합니다.
◦ 이 경우 아무나 해당 폴더를 삭제할 수 있으나 sticky bit을 주는 경우 삭제 등의 일부 권한이 제한
됩니다.
◦ /tmp 등 여러 사용자가 공유하는 폴더에 사용합니다.

29. 번외편) Windows access control
◦ Linux와 달리 각 보안 주체에 대해 허가/거
부를 설정할 수 있으며, 부모 폴더로부터의
상속을 지원합니다.
◦ Professional edition 이상에서만 access
control을 수정할 수 있는 보안 탭을 사용할
수 있습니다.
◦ 터미널 프로그램 icacls도 있습니다.
◦ 리눅스의 root와는 달리 윈도우의
Administrator도 일반 사용자와 마찬가지로
보안 설정에 따라 파일에 엑세스 할 수 있습
니다.

30. 번외편) Inside of Windows ACL
◦ Linux에서와 같은 setuid 시스템콜 대신, 각 프로세스는 특정 사용자를 나타내는 handle을 가지고
그 사용자로서 작업을 수행할 수 있습니다.
◦ 다른 사용자의 비밀번호를 옳게 입력하면 해당 사용자의 handle을 주는 시스템콜이 존재합니다.
◦ 시스템 관리자 계정의 경우, 일반 사용자용 handle과 관리자용 handle 2개를 사용할 수 있습니다.
◦ 관리자를 위한 ACL의 예외, Backup, Restore Security Privilege가 존재합니다.

31. Need more isolation
◦ 만일 user를 사용할 수 없는 경우에는 어떻게 해야 할까요?
◦ 시스템 관리자가 아닌 일반 사용자는 user를 생성할 수 없습니다.
자신이 소유한 파일을 안전하게 보호하며 서비스를 돌릴 수는 없을까요?
◦ 어떠한 이유가 있어서 root로 서비스를 실행해야 합니다.
이 경우에 시스템을 보호할 다른 방법은 없을까요?

32. Available solutions
◦ Virtualization
◦ Sandboxing
◦ SELinux

33. Virtualization
◦ 여러분이 (아마도) 많이 사용해 봤을 가상 머신을 이용합니다.
◦ 완전히 새로운 시스템을 구축해야 하기 때문에 리소스를 많이 사용하나 호스트와 완전히 격리된
환경을 생성할 수 있습니다.

34. Sandboxing
◦ 사실 가상 머신을 사용하는 것도 일종의 sandboxing입니다.
◦ 다양한 방법이 존재하겠으나 리눅스에서 사용 가능한 firejail을 봅시다.

35. Introducing firejail! - 불감옥
◦ 리눅스 커널의 namespace 기능을 이용합니다.
◦ 프로세스에게 다른 namespace를 주어 기존 환경으로부터 격리하는 것이 가능합니다.
◦ 실행해봅시다!
firejail <program>

37. Firejail - 불감옥
◦ 사용하기 간편합니다.
◦ Firefox, libreoffice, slack 등 대부분의 프로그램을 위한 프로필이 이미 만들어져 있습니다.
◦ 프로그램을 firejail과 함께 실행하도록 링크를 만들어주는 firecfg란 tool을 제공합니다.
◦ 상세한 제어가 가능합니다.
◦ 특정 폴더의 접근 거부 가능
◦ 특정 프로토콜(ipv4, ipv6, unix socket 등)의 사용 거부 가능
◦ procfs, sysfs로의 접근 거부 가능
◦ 독립된 /tmp 폴더를 사용하도록 설정 가능
◦ /etc로의 제한적인 접근만을 허가할 수 있음
◦ Firejail container 안에서 다른 hostname을 사용하도록 설정 가능
◦ 다른 사용자의 홈 디렉토리의 존재 자체를 볼 수 없게 설정 가능
◦ 등등…

38. Firejail – 파일 접근 제어 예시
◦ Firejail container 내에서 실행 중인 shell입
니다.
◦ 접근이 제한된 파일 및 폴더가 nobody의 소
유로 표시됩니다.

39. Firejail – 프로그램 및 소켓 제어 예시

40. Firejail – 사용자 제한
◦ 각 사용자가 sandbox 내에서만 작업을 수행할 수 있도록 만들 수도 있습니다.
◦ 사용자의 login shell을 firejail로 변경하면 됩니다.

41. SELinux
◦ Security-Enhanced Linux
◦ Linux에서 기본적으로 제공하는 access control 이상의 상세한 제어가 필요한 경우 사용합니다.

42. Mandatory access control
◦ SELinux의 보안 정책은 시스템 관리자가 설정하며, 일반 유저는 수정할 수 없습니다.

43. SELinux context
◦ 각 object(파일)과 subject(프로세스)는 context를 갖습니다.
◦ Context는 user, role, type, level로 구성됩니다.
◦ Object와 subject의 context에 따라 읽기, 쓰기, 실행 등을 허가할 규칙을 설정할 수 있습니다.

44. SELinux on distributions
◦ Ubuntu -> selinux 패키지를 설치하여 사용 가능합니다.
◦ ArchLinux -> 관련 aur 패키지를 설치하여 사용 가능합니다.
◦ Android -> 4.3 버전부터 SELinux 지원을 시작했고, 이후 사용이 의무화 되었습니다.

45. Subject context

47. Object contexts

48. Thx.
◦ Any questions?