Type Enforcement
아 댄장
HTML에서 쓰다보니 띄워쓰기를 안 넣었네.
br 좀 써줬어야 하는데... 에디터 플러스에서 HTML 기능으로 메모하던던 전혀 쓸모 없었던 것 같다.
lObject(s): items in a system that are acted upon (files, IPC, sockets, etc….)lSubject(s): process that are requesting access to an objectlAll Objects and Subjects contain a security contextlSecurity Context(s) are composed of four partslAll Security Context components are checked against the policy to see if access is allowed.
lType is the base component while role and user are used to further restrict type enforcement
사실 이부분은 복습인데...(블로거에서 글자 크기 조정하려면 이전에 썼던 글을 Ctrl+C V 하면 되는구나)
object들은 리눅스의 모든 것이고 subject는 프로세스라고 보면 되겠다. 오브젝트와 서브젝트는 selinux가 케어하는 모든 부분이고 security context로 이름을 붙인다.
모든 security context는 allowd 되었는지 검사가 되는 것이고 타입은 기본적인 컴포넌트, 반면 롤과 user는 더 TE로 제한하기 위한 것이다.
기본적은 타입이란 놈을 이용해서 제어를 하고(.te파일은 type enforcement니까)
role과 user 별로 제어를 할 수도 있다는 말이다.
system_u:object_r:passwd_exec_t:s0:c0.c2-s2:c0.c1
user:role:type:sensitivity[:category,…][-sensitivity[:category,…]]
이건 앞부분에서 했는데 mls에 대한 내용이 나왔다. sensitivity이랑 category라는 거....
s랑 c의 이름은 알게 되었다.
TE Access Control
_> TE파일 구조...
allow user_t bin_t : file { read execute write getattr setattr}
로 되어 있음녀
User_t는 도메인 타입으로 도메인은 프로세스 타입이라고 했다. 파일이라도 메모리에 올라가면 프로세스가 되는거니까... 어떤 타입에 접근하고자 하는 Source type이다.
bin_t는 타겟 타입이고. The type of the object being accessed by the process 라고 하는 걸 봐서. 프로세스끼리는 아니고 object 단위인가 보다. 여기서 혼돈이 발생한다. ㅡㅡ; 뭔가 프로세스 끼리도 통제를 할 것 같은데 결국 subject도 object가 실행된 녀석이고. 실행은 안 되었더라도 subject(process)에 종속된 리소스들일 것 아닌가?
이런 애매한 것들은 계속 쓰다보면 자연스럽게 익숙해 지는 것들이라 넘어 가면 된다.
file은 object class다. 얘는 앞쪽에 나왔던 41개 중에 하나인 것이다.
{}안에는 Permissions지. 20개 짜리.
PPT 붙여 넣기도 귀찮으니 읽고 핵심 요약만 하겠다. selinux ppt는 인터넷에 널렸다.
selinux filetype:ppt나 pdf로 검색하면 수두루루룩. 구글신 만세~
user_t는 untrusted user다. 뭐 다른 도메인으로 정할 수는 있겠으나 예약어 처럼 쓰이는데 의미가 참 충격적이다.
selinux에서 말하는 user랑 DAC(리눅스 기본 uid, gid 뭐 그런거..)에서 말하는 user는 다른 user다.
LSM 리눅스 시큐리티 모델을 위한 커널 프레임웍이다.(Linux Security Model)의 약자겠지.
시큐리티 첵을 위한 후킹셋을 제공한다.
보통은 DAC 체킹을 위해 쓰인다.
MAC은 DAC fail이면 불리지 않는다. 이건 겁나 중요한 대목인 것 같다.
결국 LSM에도 if(DAC fail) then MAC 아니 else MAC해바바
인 것이다. SELinux에 LSM도 포함된다고 해야 하나 LSM에 SElinux에 포함된다고 해야 하나... 그건 소스를 보야...
관련 자료... 특히 그림을 쭉 훑어 보니
LSM module 은 커널단에 위치하고 있고 Selinux FileSystem을 통해서 User 단에서 접근한다. 리눅스에서 참 익숙한 모델이다. 모든게 File 로 취급하는 리눅스 철학이랑 같다.
Access Vector Cache 라는 애도 봉니다.
Security Server라는 놈이 Policy Checking을 하지만 중간에 캐시를 둬서 더 빠르게 하려는 것이겠지. 자세한건 소스편에서.
Policy소스는 policy.conf로 통합된다.(그림 상으론)
Types, TE Rules, Roles, Users...랑 리소스 레이블링 내용 제한 내용 클레스랑 퍼미션들...
policy.conf는 Checkpolicy에 의해 Binary Policy File로 바뀌어서
load_policy에 의해 로드된다.
바이너리로 바뀌기 직전 policy가 policy.conf라는게 너무너무너무 중요하다.
얜 안드로이드의 경우
androut out target product xxxxx obj ETC sepolicy_intermediates에 저장된다.
바이너리는 sepolicy: 파일인데
file 명령어로 때려보면 SE Linux policy v24 MLS 8 symbols 7 ocons 라고 되어 있다.
앞에 포스팅중 android system core toolbox 에서 file.c가 없었기 때문에
걘 패치할 필요가 없었다... 뭐... adb shell에서 file이란 명령어 때릴 필요는 없으니까.
(보안산 adb shell은 최소한으로 유지한다)
내 폰만을 위한 커스터 마이징 빌드때는 busybox에 bash쉘 포팅했었는데 무쟈게 편했었다. 탭도 먹고 흐흣.
(하실려는 분들은 이미지가 커지면 문제가 좀 생길수도 있음을 잊지 마시고...)
길게 썼네 마무리 멘트는
Object Classes
-File related (blk_file,chr_file,dir,fd …)
-Network related (socket, packet_socket, rawip_socket, …)
-IPC related (ipc, msg, msgq, sem, shm)
-Misc Classes (capability, process,
security, system)
마무리 할랬는데... process는 왜 misc에 들어가고 object classes에 들어가는거야 ㅡㅡ; 써글. 암튼 좋은 자료들도 다 혼돈을 준다니깐.
블락/케릭터 디바이스 파일ㅇ나 디렉토리, 파일 디스크립터 들은 익숙한데 misc에 있는 시큐리티나 capability는 뭐하는 친구들일까?
008 부터는 삽질 이야기 좀 적어야 겠다.
답글삭제