root 권한을 가진 프로세스는 모든 파일에 접근할 수 있습니다.
프로세스가 어떤 스맥레이블로 활성화되어있건 관계가 없죠.
사실 약간 깡패같은 느낌이 없잖아 있습니다.
그게 root의 막강한 권한이기도 하지요.
그렇지만, 플랫폼을 제품으로 출시할때,
root 권한은 최대한 제한하고 없애야 합니다.
스맥을 사용하는 시스템에서는 onlycap이 좋은 시작이 될 수 있습니다.
특정 스맥레이블을 onlycap이라 설정하고,
onlycap만이 "스맥레이블을 명시하지 않아도" 모든 파일에 접근할 수 있게 합니다.
이 말은 root라 할지라도 onlycap이 아니면 모든 파일에 접근할 수 없다는 말이지요.
스맥이 활성화된 커널에서는 CAP_MAC_ADMIN을 가진 프로세스만이 스맥레이블을 변경할 수 있습니다.
CAP_MAC_ADMIN은 보통 관리자 권한의 프로세스가 가지고 있습니다.
일반적으로 root 권한으로 실행되는 프로세스가 관리자 권한이라고 여겨지지요.
CAP_MAC_ADMIN 프로세스만이 프로세스, 파일, 디렉토리에 명시된 스맥레이블을 변경할 수 있습니다.
CAP_MAC_OVERRIDE는 접근하려는 오브젝트에 어떤 레이블이 걸려있든 접근할 수 있는 권한입니다.
이것도 보통 관리자 권한이 지닌 막강한 권한 중에 하나입니다.
CAP_MAC_OVERRIDE 프로세스는 어떤 스맥레이블이 새겨진 파일이든 상관없이 접근합니다.
CAP_MAC_ADMIN이나 CAP_MAC_OVERRIDE는 막강한 권한입니다.
이런 권한을 가진 프로세스를 최대한 제한해야 시스템이 루팅으로부터 벗어날 수 있습니다.
곧, 관리자 권한의 프로세스라 하더라도 CAP_MAC_ADMIN이나 CAP_MAC_OVERRIDE를 제한해야한다는 것입니다.
If /smack/onlycap is empty (unset or null-string) privilege
is enforced in the normal way. If /smack/onlycap contains a label only processes running with that label may be MAC exempt. If the label in /smack/onlycap is the star label ("*") the semantics of the star label combine with the privilege restrictions to prevent any violations of MAC, even in the presence of privilege.
smack: limit privilege by label
onlycap은 2008년 7월 30일에 커널에 반영된 기능입니다.
/smack/onlycap에 명시된 스맥레이블을 가진 프로세스만이 CAP_MAC_OVERRIDE 기능을 사용할 수 있게 합니다.
관리자 권한을 가진 프로세스라 하더라도,
onlycap에 명시된 스맥레이블로 지정되어 있지 않다면,
자신이 룰셋에 정의한 스맥레이블에만 접근할 수 있습니다.
리눅스권한 레벨에서는 관리자권한이라 할지라도,
스맥 레벨에서는 일반유저와 동일한 수준의 권한을 가지게 되는 셈입니다.
/smack/onlycap파일에 어떤 값을 채우느냐에 따라 동작이 달라집니다.
- onlycap을 비워두면, 관리자 권한을 가진 프로세스들이 모든 파일에 접근할 수 있습니다.
- onlycap에 스맥레이블을 채워놓으면, 명시된 레이블로 실행되는 프로세스만이 모든 파일에 접근할 수 있습니다.
- onlycap에 "*"를 넣으면, onlycap 권한이 제한됩니다.
onlycap 파일은 CAP_MAC_ADMIN이나 CAP_MAC_OVERRIDE 권한을 지닌 프로세스만이 수정할 수 있습니다.
관리자 권한을 가진 프로세스라 할지라도 CAP_MAC_ADMIN이나 CAP_MAC_OVERRIDE가 없다면,
/smack/onlycap를 수정하여 시스템 해킹을 시도할 수 없겠죠.
Smack onlycap allows limiting of CAP_MAC_ADMIN and CAP_MAC_OVERRIDE to
processes running with the configured label. But having single privileged
label is not enough in some real use cases. On a complex system like Tizen,
there maybe few programs that need to configure Smack policy in run-time
and running them all with a single label is not always practical.
This patch extends onlycap feature for multiple labels. They are configured in the same smackfs "onlycap" interface, separated by spaces.
[PATCH 2/2] Smack: allow multiple labels in onlycap
onlycap과 관련된 따끈따끈한 패치도 있네요.
2015년 5월 21일에 리눅스 커널에 올라왔습니다.
패치는 onlycap에 다수의 스맥레이블을 등록할 수 있게 되었습니다.
(기존에는 오직 하나의 스맥레이블만 적을 수 있었습니다)
/smack/onlycap에 스페이스로 구분된 스맥레이블을 적어주면 됩니다.
위에 잠깐 언급되어 있지만, 타이젠 같은 복잡한 시스템을 위해 패치를 만들었네요.
끝_
* SMACK에 대한 이야기를 쌓아본다
http://storycompiler.tistory.com/51
* References
https://www.kernel.org/doc/Documentation/security/Smack.txt
https://lwn.net/Articles/292128/
'IT' 카테고리의 다른 글
[SQLite] SQLite의 새로운 수익모델 (0) | 2015.06.21 |
---|---|
[algospot/알고리즘] 알고스팟에서 HELLOWORLD 문제풀기 (0) | 2015.06.20 |
[Ubuntu/Linux] 우분투 터미널을 위한 최적화된 색상 (4) | 2015.06.19 |
[Ubuntu/Linux] vim에서 edc, embryo, eo 가독성 높이기 (0) | 2015.06.18 |
[Ubuntu/Linux] vimrc의 모든 것 (1) | 2015.06.17 |
[SMACK] 스맥에 대한 이야기를 쌓아본다 (0) | 2015.06.14 |
[SMACK] 스맥 레이블을 긋기 위한 manifest의 모든 것 - DBUS편 (0) | 2015.06.14 |
[SMACK] 스맥 레이블을 긋기 위한 manifest의 모든 것 - 파일편 (1) | 2015.06.13 |
[SMACK] 스맥체크의 7가지 단계 (0) | 2015.06.12 |
[EFL] EFL 윈도우를 가속하여 보자 (2) | 2015.06.12 |