엘 캐피 탄의“루트리스”기능은 무엇입니까?

엘 캐피 탄의 "루트리스 (Rootless)"기능에 대해 방금 배웠으며 "루트 사용자가 없습니다", "수정할 수있는 것이 없음 /System"및 "루트를 얻을 수 없기 때문에 세상이 끝날 것"과 같은 소식을 듣고 있습니다.

기술 수준에서 El Capitan의 "Rootless"기능은 무엇입니까? 실제로 사용자 경험과 개발자 경험에 어떤 의미가 있습니까? 윌 sudo -s여전히 그렇다면, 작업, 그리고 어떻게 것 같은 쉘 사용 경험 root변화를?

첫 번째 : 루트 계정이 아직 남아 있기 때문에 "rootless"라는 이름은 잘못된 것으로, 여전히 액세스 할 수 있습니다 (공식 이름 인 "System Integrity Protection"이 더 정확함). 실제로하는 일은 루트 계정의 권한을 제한하여 루트가 되더라도 시스템을 완전히 제어 할 수는 없습니다. 본질적으로 아이디어는 맬웨어가 루트 액세스를 얻는 것이 너무 쉽다는 것입니다 (예 : 사용자에게 인증 대화 상자를 표시하여 사용자가 관리자 암호를 재귀 적으로 입력하게 함). SIP는 또 다른 보호 계층을 추가합니다. 멀웨어는 루트에 도달하더라도 침입 할 수 없습니다. 물론 이것의 나쁜 부분은 의도적으로하는 일에도 적용되어야한다는 것입니다. 그러나 루트에 대한 제한은 그렇게 나쁘지 않습니다. 그들은 대부분의 "정상"을 막지 않습니다

루트에서도 제한 사항은 다음과 같습니다.

• 당신은 아무것도 수정할 수 없습니다 /System, /bin, /sbin, 또는 /usr(제외 /usr/local); 또는 내장 앱 및 유틸리티 중 하나. 설치 프로그램 및 소프트웨어 업데이트 만 이러한 영역을 수정할 수 있으며 Apple 서명 패키지를 설치할 때만 해당 영역을 수정할 수 있습니다. 그러나 일반적인 OS X 스타일 사용자 정의는 /Library(또는 ~/Library, 또는 /Applications), 유닉스 스타일 사용자 정의 (예 : Homebrew)는 /usr/local(또는 때때로 /etc또는 /opt) 들어가기 때문에 큰 문제는 아닙니다. 또한 시동 디스크에 블록 수준의 쓰기를 방지하므로 이러한 방식으로 바이 패스 할 수 없습니다.

  제한된 디렉토리의 전체 목록 (및 기타를 제외 /usr/local하고는 예외 )은에 /System/Library/Sandbox/rootless.conf있습니다. 물론이 파일 자체는 제한된 영역에 있습니다.

  El Capitan으로 업그레이드하면 "권한이없는"파일이 제한된 영역에서로 이동됩니다 /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• 디버깅 (또는로드하는 동적 라이브러리 또는 다른 것 변경)과 같은 시스템 프로세스 (예 : 해당 시스템 위치에서 실행되는 프로세스)에 연결할 수 없습니다. 다시 말하지만, 큰 문제는 아닙니다. 개발자는 여전히 자신의 프로그램을 디버깅 할 수 있습니다.

  내장 Apple 앱 (특히 Finder)에 코드를 삽입하는 것과 같은 중요한 기능을 차단합니다. 또한 dtrace시스템 모니터링을위한 도구 (예 opensnoop:)는 많은 시스템 프로세스를 모니터링 및보고 할 수 없습니다.

• 커널 확장 (kext)이 제대로 서명되지 않으면 (예 : Apple 또는 Apple 승인 개발자가) 커널 확장 (kext)을로드 할 수 없습니다. 이것은 kext signing을 시행하는 기존 시스템과이를 우회하는 기존 방식을 대체합니다. 그러나 v10.10.4 Apple은 써드 파티 SSD에 대한 트림 지원을 활성화 할 수있는 방법 이 있었기 때문에 서명되지 않은 kext를 사용하는 가장 큰 이유는 사라졌습니다.

• Sierra (10.12)부터는 시작된 일부 구성 설정을 변경할 수 없습니다 (예 : 일부 시작 데몬을 언로드 할 수 없음).

• Mojave (10.14)부터는 사용자의 개인 정보 (이메일, 연락처 등)에 대한 액세스가 사용자가 해당 정보에 액세스하도록 승인 한 앱으로 제한됩니다. 이것은 일반적으로 별도의 기능 (개인 정보 보호 또는 TCC라고 함)으로 간주되지만 SIP를 기반으로하며 SIP를 비활성화하면 비활성화됩니다. 참조 : "맥 OS 모하비 응용 프로그램을 개인 데이터에 대한 액세스를 제한하기 위해 구현 않는 방법은 무엇과?"

이러한 제한을 원하지 않는 경우-허용 범위를 넘어서 시스템을 수정하거나 이러한 제한에서 실용적이지 않은 kext와 같은 것을 개발 및 디버깅하기 때문에 SIP를 끌 수 있습니다. 현재이 복구 모드로 부팅하고 명령을 실행이 필요합니다 csrutil disable(당신은 유사으로 다시 활성화 할 수 있습니다 csrutil enable).

SIP의 일부 를 선택적으로 비활성화 할 수도 있습니다 . 예를 들어 csrutil enable --without kextSIP의 커널 확장 제한을 비활성화하지만 다른 보호 기능은 그대로 둡니다.

그러나 SIP를 일시적 또는 부분적으로 비활성화하기 전에 중지하고 생각하십시오. 실제로 SIP를 비활성화해야합니까, 아니면 원하는 방식으로 더 나은 (SIP 호환) 방법이 있습니까? 당신은 정말 뭔가 수정해야합니까 /System/Library하거나 /bin또는 무엇이든을, 또는 같은 더 좋은 곳으로 갈 수 /Library또는 /usr/local/bin등? SIP는 익숙하지 않은 경우 제약을 느끼게 할 수 있으며,이를 비활성화해야하는 합법적 인 이유가 있지만 실제로는 실제로 최선의 방법을 강요하는 많은 이유가 있습니다.

가능한 한 많은 시간 동안 SIP를 사용하도록 설정하는 것이 중요하다는 점을 강조하기 위해 2019 년 9 월 23 일 이벤트를 고려하십시오. Google은 기호 링크를에서 (으) /var로 대체하려고 시도한 Chrome 업데이트를 출시했습니다 /private/var. 대부분의 시스템에서 SIP는이를 차단했으며 나쁜 영향은 없었습니다. SIP가 비활성화 된 시스템에서는 macOS가 고장 나고 부팅 할 수 없었습니다. SIP를 비활성화하는 가장 일반적인 이유는 승인되지 않은 (/ 부적절하게 서명 된) 커널 확장 (특히 비디오 드라이버)을로드하는 것이 었습니다. 그들이 kext 제한 만 비활성화했다면 영향을받지 않았을 것입니다. 참조 공식 Google 지원 스레드 , 그것에 수퍼 유저 Q & A 및 아르스 테크니카 문서를 .

참고 자료 및 추가 정보 : "보안 및 사용자 응용 프로그램" 에 대한 WWDC 프레젠테이션 , quora.com의 Eldad Eilam 의 좋은 설명 , El Capitan 의 Ars Technica 검토 및 SIP에 대한 Apple 지원 기사 및 Rich Trouton의 심층 분석 ( 이 질문 에 대한 답변을 게시 한 사람 ).

저에게는 DTrace가 더 이상 작동하지 않는다는 것을 의미합니다.

DTrace는 Linux에서 ptrace / strace와 유사합니다. 프로세스가 커널에 무슨 말을하는지 알 수 있습니다. 프로세스가 파일 열기, 파일 쓰기 또는 포트 열기 등을 원할 때마다 커널에 문의해야합니다. Linux에서이 모니터링 프로세스는 "userland"의 커널 외부에서 발생하므로 권한이 매우 세분화됩니다. 사용자는 버그를 수정하고 메모리 누수를 찾기 위해 자신의 응용 프로그램을 모니터링 할 수 있지만 다른 사용자의 프로세스를 모니터링하려면 루트 여야합니다.

그러나 OSX의 DTrace는 커널 수준에서 작동하여 훨씬 성능이 뛰어나고 강력하지만 프로브를 커널에 추가하여 무엇이든 할 수있는 루트 액세스가 필요합니다. 사용자는 루트가 아닌 자신의 프로세스를 추적 할 수 없지만 루트로서 자신의 프로세스를 볼 수있을뿐만 아니라 실제로 시스템의 모든 프로세스를 동시에 볼 수 있습니다. 예를 들어, 파일 (iosnoop 포함)을보고 어떤 프로세스가 파일을 읽는지 확인할 수 있습니다. 이것은 맬웨어를 탐지하는 데 가장 유용한 기능 중 하나입니다. 커널도 네트워크 IO를 다루기 때문에 마찬가지입니다. Wireshark는 비정상적인 네트워크 활동을 감지하고 DTrace는 데이터를 커널 자체처럼 시스템에 내장하더라도 데이터를 보내는 프로세스를 알려줍니다.

그러나 엘 캐피 탄은 애플이 DTrace가 작동하지 못하도록 의도적으로 막아 버렸다. SIP가 제한하는 것으로 구체적으로 타깃팅되고 선별 되었기 때문이다. 그들은 왜 이것을 할 것입니까? 글쎄, 이전에 애플은 커널과 DTrace를 수정하여 일부 프로세스가 DTrace를 통해 모니터링되지 않도록했다 (이는 일부 프로세스가 이제는 루트를 포함하여 악성 코드를 포함하더라도 한계를 벗어 났기 때문에 많은 보안 연구원들을 화나게했다). 이론적으로 누군가가 프로세스 메모리에서 DTRM없이 데이터를 DTrace하고 가져올 수 있기 때문에 iTunes와 같은 앱에서 DRM을 보호해야했습니다.

그러나 연구원들이 계속해서 작업을 수행 할 수 있도록하는 중요한 해결 방법이 있었고,이 옵트 아웃 플래그를 무시하도록 커널을 수정하여 DTrace를 이러한 프로세스에서 계속 사용할 수있었습니다. 이 no-DTrace 플래그로 불이 켜진 곳에서 탐지를 피하려고 시도하는 프로그램 때문에 실제로 실제로 훌륭했습니다. 애플이나 나쁜 사람들이 숨기고 싶었던 것은 이제는 분명해 보인다 ...

그러나 지금은 작동하지 않으므로 어떻게 이것이 당신에게 영향을 줍니까? 글쎄, 그것은 당신에게 직간접 적으로 영향을 미칠 것입니다. 직접 시스템을 모니터링하는 기능이 제한됩니다. 많은 수의 저수준 시스템 관리 및 모니터링 도구 (상위 도구가 구축 됨)는 더 이상 작동하지 않습니다. 그러나 간접 효과는 훨씬 더 커질 것입니다. 보안 전문가는 최악의 종류의 위협을 탐지하기 위해 깊은 시스템 액세스에 의존합니다. 우리는 더 이상 그렇게 할 수 없습니다. 디버거 또는 허니팟에서 실행중인 것을 모르는 맬웨어를 분석 할 때 중요합니다. SIP를 비활성화하면 악의적 인 사용자와 Apple의 모든 소프트웨어에이 시스템이 감시되고 있음을 알립니다. 더 이상 감시자를 보지 않아도됩니다. SIP가 보안에 관한 것이면 사용자에게 루트에 대해 교육 할 수 있었지만 대신 제거했습니다. 궁극적으로 이것은 Apple이 루트 암호의 '모두가 되어라'보안 장벽을 '모두가 되어라'SIP 보호 메커니즘으로 대체했다는 의미입니다. 또는 사회 공학에 능숙하다면 재부팅 한 루트 비밀번호 ...

이것도 있습니다 :

SIP (System Integrity Protection)는 시스템 파일 및 프로세스가 타사에 의해 수정되는 것을 방지하기위한 전반적인 보안 정책입니다. 이를 달성하기 위해 다음 개념이 있습니다.

• 파일 시스템 보호
• 커널 확장 보호
• 런타임 보호

파일 시스템 보호

SIP는 Apple 이외의 당사자가 특정 디렉토리에 저장된 디렉토리 및 파일을 추가, 삭제 또는 수정하지 못하게합니다.

/bin
/sbin
/usr
/System

Apple은 개발자가 액세스 할 수있는 다음 디렉토리를 표시했습니다.

/usr/local
/Applications
/Library
~/Library

를 /usr제외한 모든 디렉토리는 /usr/localSIP로 보호됩니다.

Apple의 자체 인증 기관에서 서명 한 설치 프로그램 패키지를 통해 SIP로 보호 된 파일 및 디렉토리를 추가, 제거 또는 변경할 수 있습니다. 이를 통해 Apple은 기존 SIP 보호를 변경하지 않고도 OS의 SIP 보호 부분을 변경할 수 있습니다.

해당 인증 기관은 Apple이 자체적으로 사용하도록 보유합니다. 개발자 ID 서명 설치 프로그램 패키지는 SIP로 보호 된 파일 또는 디렉토리를 변경할 수 없습니다.

보호되는 디렉토리를 정의하기 위해 Apple은 현재 파일 시스템에 두 개의 구성 파일을 정의했습니다. 기본 위치는 아래 위치에 있습니다.

/System/Library/Sandbox/rootless.conf

여기서 rootless.confSIP가 보호하고있는 모든 응용 프로그램 및 최상위 디렉토리 가 나열됩니다.

응용

SIP는 OS X이 응용 프로그램 및 응용 프로그램 유틸리티에 설치하는 핵심 응용 프로그램을 보호합니다. 이는 루트 권한을 사용하는 경우 명령 행에서도 OS X가 설치하는 애플리케이션을 더 이상 삭제할 수 없음을 의미합니다.

디렉토리

SIP는 또한 외부의 많은 디렉토리와 심볼릭 링크를 보호하고 /Applications있으며 해당 디렉토리의 최상위 레벨도에 나열되어 rootless.conf있습니다.

Apple은 보호 외에도 rootless.conf 파일에서 SIP 보호에 대한 일부 예외를 정의했으며 이러한 예외에는 별표가 표시되어 있습니다. SIP의 보호에서 이러한 면제는 해당 위치 내에서 파일 및 디렉토리를 추가, 제거 또는 변경할 수 있음을 의미합니다.

이러한 예외는 다음과 같습니다.

• /System/Library/User Template -OS X은 새 계정의 홈 폴더를 만들 때 사용하는 템플릿 디렉토리를 저장합니다.
• /usr/libexec/cups -OS X이 프린터 구성 정보를 저장하는 위치

Apple은이 파일을 파일로 간주하고 Apple이 해당 파일에 대한 제 3 자의 변경 사항을 덮어 씁니다.

SIP로 보호 된 파일을 보려면 터미널에서 dash capital O와 함께 ls명령 을 사용하십시오 .

ls -O

SIP로 보호 된 파일은 제한된 것으로 표시됩니다 .

알아야 할 한 가지 중요한 생각은 심볼릭 링크가 SIP로 보호 되더라도 반드시 링크하는 디렉토리가 SIP에 의해 보호되고 있음을 의미하지는 않습니다. OS X El Capitan 부트 드라이브의 루트 레벨에는 루트 레벨 디렉토리 안에 저장된 디렉토리를 가리키는 여러 SIP 보호 심볼릭 링크가 private있습니다.

그러나 private디렉토리 의 내용을 검사 할 때 해당 심볼릭 링크가 가리키는 디렉토리는 SIP에 의해 보호되지 않으며 루트 권한을 사용하는 프로세스에 의해 해당 내용과 내용을 이동, 편집 또는 변경할 수 있습니다.

Apple에서 설정 한 SIP 예외 목록 외에도 SIP 예외 rootless.conf의 두 번째 목록이 있습니다. 이 목록에는 타사 제품의 여러 디렉토리 및 응용 프로그램 이름이 포함됩니다. 와 rootless.conf마찬가지로이 제외 목록은 Apple의 것이며 제 3 자의 변경 사항은 Apple에서 덮어 씁니다.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

런타임 보호

SIP의 보호는 파일 시스템 변경으로부터 시스템을 보호하는 것으로 제한되지 않습니다. 기능이 제한되는 시스템 호출도 있습니다.

• EPERM과 함께 task_for_pid () / processor_set_tasks () 실패
• exec (2)에서 Mach 특수 포트가 재설정 됨
• dyld 환경 변수는 무시됩니다
• DTrace 프로브 사용 불가

그러나 SIP는 개발중인 자체 응용 프로그램 개발자가 검사를 차단하지 않습니다. Xcode의 도구는 개발 프로세스 중에 앱을 계속 검사하고 디버깅 할 수 있도록합니다.

이에 대한 자세한 내용 은 SIP에 대한 Apple 개발자 문서를 참조하십시오 .

커널 확장 보호

SIP는 서명되지 않은 커널 확장의 설치를 차단합니다. SIP가 활성화 된 OS X El Capitan에 커널 확장을 설치하려면 커널 확장이 다음과 같아야합니다.

1. Kexts 인증서 서명을위한 개발자 ID로 서명
2. / Library / Extensions에 설치

서명되지 않은 커널 확장을 설치하는 경우 SIP를 먼저 비활성화해야합니다.

SIP 관리에 대한 자세한 내용은 아래 링크를 참조하십시오.

시스템 무결성 보호 – Apple 보안 모델에 다른 계층 추가