selinux 005 둘러보기

소스는 쉬어 가는 페이지 인가...

SELinux에서 SEAndroid가 나왔다.

둘다 NSA 프로젝트이고.

이미 여러 패키지에 흩어져서 사용되고 있다.

policycoreutils는 tresys에서 만든 것으로 보인다.

www.tresys.com에 가면 좋은 자료들이 많다. 

포팅은 이미 안드로이드 메인브랜치에 되고 있고

정책은 트레시스에서 나오는 자료들을 참고하면 된다.

ⓒ 2002 - 2005 Tresys Technology, LLC (www.tresys.com/selinux, selinux@tresys.com) 7

.. SELinux defines 41 kernel object classes

.. Each with their own fine-grained permissions

.. For example, file object class has 20 permissions:

ioctl read write

create getattr setattr

lock relabelfrom relabelto

append unlink link

rename execute swapon

quotaon mounton execute_no_trans

entrypoint execmod

.. Documentation available at www.tresys.com/selinux

Object Classes and Permissions

key_socket

ipc netlink_nflog_socket rawip_socket unix_stream_socket

filesystem netlink_kobject_uevent_socket process unix_dgram_socket

file netlink_ip6fw_socket passwd udp_socket

fifo_file netlink_firewall_socket packet_socket tcp_socket

fd netlink_dnrt_socket node system

dir netlink_audit_socket netlink_xfrm_socket socket

chr_file netif netlink_tcpdiag_socket sock_file

capability msgq netlink_socket shm

blk_file msg netlink_selinux_socket sem

association lnk_file netlink_route_socket security

트레시스 사이트 들어가면 PDF가 있는데 그 안에 내용이다.

SELINUX에서는 41개의 커널 오브젝트 클레스를 정의해 놓고

동작은 20개를 정의해 놓았다. 2005년도 자료라 지금은 또 달라졌겠지.

믓튼,

시스템콜을 막는다고 하면 얼추맞는 표현일 것 같다.

일반적으로 리눅스 시스템에서

rwxrwxrwx 로 구성된 보안에서 한단계 업글된 보안이라고 봐도 되겠다.

root 권한을 획득하면 아무 파일에나 접근할 수 있었지만 root도 하나의 context로

분류되어서 다른 context로의 권한이 없으면 접근하지 못한다.

rwx를 dac, selinux를 mac 타입이라고 한다. 영어는 어렵다.

mac는 멘데터리 액세스 컨트롤 mandatory Access Control 이다.

법에 정해진대로 한다는 거지. root가 맘대로 바꿀 수 있는게 아니라.

즉, 더 이상의 super user는 없다는 이야기.(뭐 해킹 안되는 시스템이야 있겠냐만은)

자잘한 해킹 빼고 지금까지 root를 획득하는게 linux 해킹의 전부 였다고 해도 과언이 아닌데

root도 할 수 있는게 제한되어 있다고 보면 되겠다.

그럼 UID, GID, file permission처럼 또 하나의 네임 텍이 붙어야 할텐데

이미 소스에서 얼핏 보았던

con

이란 녀석

context의 줄임이고 SELinux에서는

security context로 통한다.

명명 규칙은 ... 

--> 나도 SEAndroid를 하다보니 감으로 때려 맞추는게 많아서 정확하진 않다. 그러나 ~ 같은데 라는 표현을 쓰기도 하지만 읽기 너무 불편한 감도 있어서 단언체로 말하는 경우도 있다. 의심해 보길 바란다. <나도 나중에 복습할 때 의심해야 하므로 적어둠> 

context의 경우

user:role:type

으로 가는데...

user가 u면

u:u_r:u_t

로 나가는 것이다.

_r은 role

_t는 type으로 보면 된다.

트레시스의 PDF 보면 [:s0:c0.c128]로 mls  identifier 로 되어 있는 부분은

multi lavel system 즉, 멀티 유저 상황에서 정의하는 부분으로 지식이 없으니 누가 댓글로 좀 알려 줬으면 지식이 탄탄해 질 것 같다.

SEAndroid를 직접 포팅할게 아니면 정책 부분밖에 할게 없는데

정책 조정을 하려면 용어를 알아야 한다.

오브젝트는 위에서 말한 41개 를 말하는 것이고

서브젝트는 프로세스를 말한다.

프로세스 타입은 도메인이라고 불린다.

도메인이란 녀석은 어디 빠지는 곳이 없구먼 ㅡㅡ;

통상 메모리에 올라가서 실행되고 있는 프로그램을 프로세스라고 하는데

소켓 같은 애들은 프로세스가 아니니까. 이런 놈들도 컨트롤을 하려면

object라는 이름으로 묶어서 프로세스(서브젝트), 기타 오브젝트(오브젝트)를 

타입으로 관리하는게 SELINUX 되시겠다.

프로세스(서브젝트)든 파일(오브젝트)던

user:rold:type 이라는 context가 붙는데

ls -Z

ps -eZ

로 볼 수 있다. Z만 붙여주면 된다는 뜻.

-r-------- root root system_u:object_r:shadow_t /etc/shadow

뭐 이런 식으로 보이는거지.

system 유저는 object 롤이고 shdow 타입을 가지고 있다는...

중요한 건 타입인데(정책을 정해야 하니까)

우리 패스워드가 저장되는 /etc/passwd의 본체 파일인 /etc/shadow는

shadow_t 이란 것이다.

요새는 대세가 우분투라 대부분 우분투를 쓸 것인데

/etc/selinux/default/users/system.users를 열어 보면

user system_u roles { system_r } level s0 range s0 - s0:c0.c1023;

user user_u roles { user_r } level s0 range s0;

user staff_u roles { staff_r sysadm_r  } level s0 range s0 - s0:c0.c1023;

user sysadm_u roles { sysadm_r } level s0 range s0 - s0:c0.c1023;

user unconfined_u roles { unconfined_r system_r } level s0 range s0 - s0:c0.c1023;

user root roles { sysadm_r staff_r  system_r } level s0 range s0 - s0:c0.c1023;

라고 되어 있다.

root의 role은 sysadm, staff, system 이란 거다. 

root는 uid 롤은 gid 정도로 생각하면 이해가 빠르다.

DAC랑 MAC 둘 다 통과해야 유저는 보안을 넘어 뭔가를 할 수 있고 

리눅스 유저들은 대부분 리눅스 기본 보안은 이해하니까 그걸로 설명해 놓았다.

누가? 트레시스가 

어디에? PDF에

덧붙이면 이렇다.

유저는 set uid를 이용해서 root권한을 잠깐 획득해서 비번을 바꾼다는 건 사람들이 다 아는 사실... 사족으로 잠시 root uid를 얻었을 때 중간에 빠져나오는 방법으로 root권한을 획득하는 방법도 있었지.

그러나 selinux에서는 allow 룰도 필요하다. 기본적으로는 다 막혀 있으니

allow user_t passwd_exec_t : file { getattr execute };

passwd 명령어로 파일을 실행하니까 user 타입이 passwd실행타입에

파일 속성을 읽고 실행할 수 있는 권한이 필요하다.

allow passwd_t passwd_exec_t : file entrypoint

allow user_t passwd_t : process transition

type_transition user_t passwd_exec_t : process passwd_t;

이런 역할을 하는데... 왜 설명이 없냐면 알 수 없기 때문.

dmesg 로 denied 되는 로그를 찍어봐야 아... 어떤 타입이 필요한 지 알 수 있다.

트레시스에서 만든 유틸인 audit2allow를 하면 쉽다.

dmesg | audit2allow

해버리면 denied 된 것을 풀어주는 allow 룰을 생성해 준다.

policy 파일은 .te 로 확장자가 붙는데

type enforce 약자다. enforcement인가?

믓튼...

간단히 allow만 추가하면 될 것 같지만 호락호락 하지만은 않다.

C처럼 assert.te 파일이 있어서 allow 못하게 하는 룰도 정의할  수 있다.

neverallow { appdomain -system_app } system_data_file:dir_file_class_set write;

요렇게 되어 있으면

allow platform_app system_data_file:sock_file { create unlink write setattr };

이럴 룰이 안 먹는다.

매크로도 있고.

냠... 공부할거 많네.

암튼, 너무 강력해서.... 사실 정책 정의만 잘해도 백신이 필요없을 정도다.

뭐.. 앱단에서는 그리 강력하지는 않다.

마켓에 seandroid 로 검색되는 앱을 하나 올렸는데

폰 터치를 다 막아서 폰을 먹통 만드는 프로그램이다.

seandroid로 막을 수 있긴 한데 그걸 막으면 서비스에서 폰 터치로 좋은 기능을 하는 앱들도 같이 막히게 된다.

SELinux(Android)의 강력함과 정책으로 막는 것과 푸는 것의 경계를 알리고자 만든건데.

쇠귀에 경읽기가 되어버렸지 모.

암튼 잘 사용되길 바란다.

SELINUX 파이팅.

그러나 난 안쓴다.