SELinux와 함께 제공되는 특정 ROM을 "Permissive"모드로 설치했습니다. 이것은 내 장치에 잘 맞는 유일한 (좋은) ROM이며 SELinux의 상태를 변경할 방법이 없습니다.

이제 나는 그러한 결정의 결과가 무엇인지 확실하지 않으며 누군가가 나에게 설명 할 수 있다면 기쁠 것입니다 (구글을 내렸고 그것이 이론적으로 무엇인지 알고 있습니다 ... 실제로는 그렇지 않습니다). 상기 ROM은 "disabled"에 근본이 있으므로 장치는 루팅되지 않은 것으로 추정되지만 SELinux와 어떻게 맞을지는 모르겠습니다.

TL; DR : 원하는 경우 하단의 결론으로 ​​직접 이동하십시오. :)!

SELinux의 목표는 권한이없는 사용자와 권한이있는 사용자의 가능한 조치를 제한하는 필수 정책을 시행하여 권한 에스컬레이션을 방지하는 것입니다.

여기서 "사용자"라는 용어는 모든 프로세스가 일부 시스템 "사용자"계정을 사용하여 실행되므로 물리적 사용자 작업 (인간, 사용자;)과 직접적으로 관계없이 장치에서 실행중인 모든 프로세스를 포함합니다.

역사적으로 Unix 기반 시스템에 대한 권한은 DAC (Discretionary Access Control) 시스템을 사용하여 처리됩니다. 이 모델에서 :

• 파일과 같은 리소스에는 소유 한 리소스에 대한 액세스 권한을 정의 할 수있는 소유자가 있습니다.이를 통해 특정 리소스가 개인 리소스인지 (소유자 만 액세스 할 수 있음) 또는 다른 사용자와 공유해야하는지 결정할 수 있습니다.
• 이 root외에도 관리 사용자이며 시스템의 모든 항목에 액세스 할 수있는 수퍼 유저 ( 유닉스 기반 시스템)가 있습니다. 이 계정은 사람 (일반적으로 시스템 관리자)이 대화 형으로 장치를 유지 관리하거나 수리 할 수 ​​있지만 일반적으로이 계정은 주로 장치 드라이버, 네트워크 구성 서비스, 서비스와 같은 권한 수준이 필요한 백그라운드 또는 낮은 수준의 서비스에 의해 사용됩니다 모든 사용자의 파일에 액세스하거나 내부 사용자 간 통신을 처리해야합니다.

이것은 매우 좋고 이미 좋은 보안을 제공합니다. 그러나 다음과 같은 상황은 어떻습니까?

1. root공격자가 서비스를 임의의 코드로 실행하도록 속일 수 있는 서비스에서 버그 가 발견되면 어떻게됩니까? 이러한 공격자는 장치에 완전히 액세스 할 수 있습니다. 구체적인 예를 들기 위해 특수하게 조작 된 네트워크 구성 정보 ( DHCP ) 또는 MMS 를 전화기 로 보내 이러한 버그가 발생할 수 있습니다 .
2. 일부 사용자가 개인 리소스를 올바르게 보호하지 않으면 어떻게됩니까? 그런 다음 권한이없는 다른 사용자가 이러한 리소스에 악의적으로 액세스 (읽기, 수정 또는 삭제) 할 수 있습니다. 일반적으로 악성 애플리케이션이 휴대 전화에서 실행될 때 (설치에 속지 않았거나 권한이없는 다른 애플리케이션, 브라우저 또는 메일 클라이언트의 버그를 사용하여 자체적으로 온 경우) 이 악의적 인 응용 프로그램은 다른 응용 프로그램 데이터 또는 저장 위치에 직접 액세스하려고 시도합니다 (일반적으로 연결할 수없는 데이터에 액세스하거나 제거를 더욱 어렵게하기 위해 여러 곳에 설치).

여기에 SELinux가 있습니다.

SELinux는 필수 액세스 제어 (MAC) 시스템입니다. 앞에서 설명한 DAC 시스템 사용자는 자신의 리소스에 대해 적절한 권한을 설정해야하지만 MAC 시스템에서는 시스템 전체 정책 (운영 체제와 함께 제공됨)이 권한있는 사용자와 권한이없는 사용자 모두에게 적용됩니다.

이렇게하면 위에서 언급 한 두 가지 문제가 다음과 같은 방식으로 해결됩니다.

1. 내가 말했듯이이 정책은 권한있는 사용자에게도 적용됩니다. 즉, 올바르게 설계된 정책을 사용하면 장치의 네트워크 구성을 처리하도록 설계된 서비스는 다른 작업을 수행 할 수 없습니다. 예를 들어 SMS에 액세스 할 수 없으며 서비스 처리 SMS는 네트워크 구성에 액세스 할 수 없습니다. 두 사용자 모두 수퍼 유저 계정을 사용하여 실행되고 있음에도 불구하고 둘 중 어느 것도 사용자의 데이터에 액세스 할 수 없습니다.
2. Android는 최근 SELinux에 의해 시행되는 다중 사용자 기능을 포함하여 사용자가 다른 사용자의 데이터에 액세스하지 못하게합니다. 그러나 SELinux 정책은 허용 된 응용 프로그램 동작을 설명 할 책임이 있으며, DAC 시스템을 사용하여 일부 리소스가 제대로 보호되지 않더라도 SELinux가 구조를 통해 악의적 인 응용 프로그램이 직접 액세스하지 못하도록합니다.

DAC와 MAC 시스템은 상호 배타적이지 않으며, 반대로 MAC 시스템 (SELinux)은 DAC 시스템 (기존의 Unix와 유사한 권한)의 두 번째 방어 계층 역할을합니다. SELinux의 역할은 DAC 시스템 만 제공된 경우 정책에 반하는 활동을 차단하는 것입니다.

까다로운 점은 이러한 정책을 작성하는 것이 매우 복잡 할 수 있다는 것입니다. 모든 상황에서 가능한 모든 사용에 대해 모든 장치의 구성 요소를 포함해야합니다. 실제로, 어떤 행동이 귀하의 상황에서 합법적 일 수 있더라도, 그것이 정책에 속하지 않으면 금지 됩니다. 따라서 잘못 설계된 정책은 응용 프로그램 충돌, 사용할 수없는 기능 등과 같은 임의의 결과를 초래할 수 있습니다.

그렇기 때문에 SELinux의 첫 번째 버전은 기본적으로 "허용"모드에 포함되었습니다. 이 모드에서 SELinux는 정책 위반 을 기록 하지만 관련 활동을 차단하지는 않습니다. 결과 로그 파일을 분석하면 정책 위반이 유일하게 악의적이거나 바람직하지 않은 동작 인 시점까지 정책을 수정하고 향상시킬 수 있습니다. 이 시점에서 SELinux는 "강제 실행"모드로 전환 될 수 있습니다. 이제 모든 위반 행위를 기록 할뿐만 아니라 차단합니다.

결론

SELinux는 완화 기술입니다. 공격자가 휴대폰에 들어가는 것을 막지는 않지만 가능한 한 적은 수의 작업을 수행 할 수 있으면 이상적으로는 아무 것도 유용하지 않으므로 처음으로 휴대폰을 공격하는 데 대한 관심을 없앨 수 있습니다.

ROM이 오래 될수록 그러한 액세스를 여는 보안 버그의 수가 많아집니다. SELinux는 이러한 알려진 취약점에도 불구하고 최소한의 안전을 유지하는 효율적인 방법이지만 SELinux가 제대로 작동하려면 복잡한 정책이 필요합니다.

ROM이 기본적으로 "허용"모드에서 SELinux와 함께 제공되는 경우, 포함 된 정책이 "강제"모드로 안전하게 전환 될만큼 충분히 신뢰할 수 없음을 의미합니다.

기술이 충분하고 전화 로그에 액세스 할 수있는 경우 ( dmesg적어도 일반적으로 복사됩니다 logcat: 후자를 볼 수있는 응용 프로그램이 있지만 Android 버전에 따라 루트 액세스가 필요할 수 있음) "avc"항목이 있습니다. 이들은 SELinux가 정책에 대한 조치를 감지했음을 나타내는 메시지입니다.

다음은 CyanogenMod 웹 사이트 에서 가져온 항목의 예입니다 .

type=AVC msg=audit(1363289005.532:184): avc: denied { read } for pid=29199 comm="Trace" 
name="online" dev="sysfs" ino=30 scontext=staff_u:staff_r:googletalk_plugin_t 
tcontext=system_u:object_r:sysfs_t tclass=file

아무 것도 없거나 몇 개가 없거나 어떤 이유로 든 전화 사용을 방해하지 않을 수 있다고 생각되면 SELinux를 "강제"모드로 전환 해보십시오. 구형 CyanogenMod ROM에서는 GUI에 숨겨진 옵션을 사용하여 쉽고 간단하게 전화를 걸거나 특정 응용 프로그램을 설치할 필요가 없었습니다. 다른 ROM이 동일한 기능을 제공했는지는 모르지만 CyanogenMod를 사용한 이후 태그 나는 당신이 운이 좋을 것 같다;).