▲

macOS의 Privacy & Security 설정을 신뢰할 수 없는 이유

 (eclecticlight.co)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • macOS의 Privacy & Security 설정이 실제 접근 권한 상태를 반영하지 못하는 문제가 확인됨
  • Documents 폴더 접근이 차단된 상태에서도 Insent 앱이 여전히 파일을 읽을 수 있는 현상이 발생
  • 사용자가 폴더를 직접 선택하면 TCC 시스템이 이를 의도적 접근으로 간주해 제약을 해제함
  • 설정 화면에는 차단된 것으로 표시되지만, 실제로는 샌드박스 제약이 해제되어 접근이 계속 허용됨
  • 접근 권한을 완전히 차단하려면 터미널 명령과 재시동이 필요하며, 이는 사용자의 제어권 상실로 이어질 위험이 있음

macOS Privacy & Security 설정의 신뢰성 문제

  • macOS Privacy & Security 설정이 실제 접근 권한 상태를 정확히 반영하지 못하는 사례가 확인됨
    • Insent이라는 간단한 앱을 이용해 Documents 폴더 접근 권한이 설정상 차단된 상태에서도 실제 접근이 가능한 현상 발생
    • 이 문제는 macOS 13.5 이상 버전에서도 동일하게 재현 가능

  • Insent 앱의 동작 방식

    • Open by consent 버튼은 사용자의 동의를 거쳐 Documents 폴더 내 임의의 텍스트 파일을 열어 표시
    • Open from folder 버튼은 사용자가 직접 폴더를 선택하면, 그 안의 파일을 열어 표시
    • 후자의 경우 사용자의 의도(intent) 가 접근 허용으로 간주되어 TCC(Transparency, Consent, and Control) 시스템이 별도의 동의 없이 접근을 허용

  • 실험 절차와 결과

    • Documents 접근을 허용한 뒤 Insent이 정상적으로 파일을 읽는 것을 확인
    • 이후 Privacy & Security 설정에서 Insent의 Documents 접근을 비활성화하면 접근이 차단됨
    • 그러나 Open from folder로 Documents를 선택하면 다시 접근이 가능해지고, 이후 Open by consent도 제한 없이 작동
    • 설정 화면에서는 여전히 접근이 차단된 것으로 표시되지만, 실제로는 Insent이 Documents 폴더에 계속 접근 가능
    • 접근을 완전히 차단하려면 tccutil reset All co.eclecticlight.Insent 명령을 실행하고 Mac을 재시동해야 함

  • 내부 동작 분석

    • Insent은 일반 공증(notarized) 앱이며, 샌드박스나 특수 권한을 사용하지 않음
    • System Integrity Protection(SIP) 이 활성화된 상태에서는 일부 작업이 샌드박스 처리됨
    • sandboxd가 파일 접근 요청을 가로채 TCC에 승인 요청을 보내며, 사용자가 동의하면 접근이 허용됨
    • 접근이 비활성화된 후에는 TCC가 접근을 거부하지만, 사용자가 Open/Save 패널을 통해 폴더를 선택하면 sandboxd가 더 이상 요청을 가로채지 않음
    • 이로 인해 TCC가 접근을 제어하지 못하고, 샌드박스 제약이 해제된 상태로 폴더 접근이 가능

  • 문제의 원인

    • 사용자의 의도에 따른 접근이 발생하면 해당 폴더에 대한 샌드박스 제약이 제거됨
    • 이 변경은 Privacy & Security 설정 UI에 반영되지 않음, 따라서 설정상 차단된 것처럼 보이지만 실제로는 접근이 허용된 상태 유지
    • 다른 보호 폴더(예: Desktop, Downloads)는 정상적으로 동작하며, 문제는 폴더별로 독립적으로 발생

  • 결론

    • Files & Folders 항목의 접근 제한 표시가 실제 적용 상태를 신뢰할 수 없음

      • 앱이 목록에 표시되지 않거나 차단된 것으로 보이더라도 실제로는 보호 폴더에 접근할 수 있는 경우 존재
      • 접근 권한이 한 번 부여되면 터미널 명령과 재시동 없이는 해제되지 않음, 이는 사용자가 접근 제어를 상실할 위험

  • 추가 논의 (댓글 요약)

    • 실험 후 Documents 폴더에 com.apple.macl 확장 속성이 추가되어 Insent의 접근을 허용하는 역할을 하는 것으로 추정
    • tccutil reset 명령은 데이터베이스의 macl 항목을 제거하지만, xattr(확장 속성) 은 남아 있어 접근이 유지될 수 있음
    • SIP가 활성화된 상태에서는 이 속성을 제거하기 어렵고, 복구 모드에서 xattr -d com.apple.macl path/to/Documents 명령으로만 삭제 가능
    • 이로 인해 사용자는 앱의 실제 접근 상태를 확인하거나 제어하기 어려운 상황에 놓임

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 내가 보기엔 단순한 문제 같음. 앱에 폴더 접근 권한을 주면 그 폴더 안의 파일에도 접근할 수 있는 건 당연한 일로 예상했음

    • 문서를 자세히 읽어야 함. Files & Folders 설정이 실제 권한 상태를 정확히 반영하지 않음. UI에서는 차단된 것처럼 보여도 앱이 여전히 Documents 폴더에 무제한 접근할 수 있음
    • 핵심은 “권한을 부여했다가 UI에서 해제했는데도 여전히 접근 가능함”이라는 점임
    • 글의 서두에서도 “보안 설정이 앱의 실제 접근 상태를 잘못 보여줄 수 있음”이라고 명시되어 있음
    • macOS가 이미 UI로 연결된 폴더를 인식하고 백엔드에서 연동해줄 거라 기대했지만, 단순 경로 예외로 처리되어 UI가 비활성화되는 문제임. 이런 건 피드백 리포트로 제출했을 듯함. 작성자는 Gatekeeper나 TCC 관련 문제를 자주 다루는 사람이라 공감됨
    • 글이 너무 불명확하게 작성되어 있음. 권한이 해제된 후에도 남아 있는 메커니즘이 무엇인지 설명이 부족함

  • 글을 읽고 나서 모든 폴더 권한을 해제하고 테스트했는데, Insent가 UI에서 “None”으로 표시되어도 Documents를 읽을 수 있었음. 투명성 실패로 보임

    • 앱이 기본적으로 사용자 홈 폴더에 접근할 수 있는 것 아닌가 하는 의문이 듦

  • GUI 중심 OS의 아이러니함임. Documents 폴더 접근을 완전히 차단하려면 터미널에서
    tccutil reset All co.eclecticlight.Insent
    명령을 실행하고 재부팅해야 함

    • Jobs가 무덤에서 뒤집힐 일임. NeXT 시절에도 이런 GUI 대 CLI 충돌이 많았다고 함
    • GUI 관련 이상한 현상도 있음. Wi-Fi를 꺼둔 상태로 종료했는데, 부팅 후 로그인 시 Wi-Fi 아이콘이 잠시 활성화된 것처럼 보였다가 비활성화로 돌아감. 단순 UI 버그인지, 실제로 잠깐 켜지는 건지 모르겠음

  • 제목은 “macOS 앱이 사용자가 접근을 해제해도 폴더 접근을 유지함” 정도로 바꾸는 게 정확함

    • 하지만 실제로는 사용자가 특정 접근을 해제한 게 아니라, 일반 폴더 접근을 해제했을 뿐임. 세부 접근을 개별적으로 해제할 방법이 없음

  • Mac의 sandbox 시스템이 Windows UAC를 떠올리게 함. 사용자의 피로감만 키우는 구조임.
    *nix의 선택적 컨테이너 방식이 훨씬 낫다고 생각함.
    Terminal에서 실행된 백그라운드 프로세스가 부모 프로세스가 죽어도 권한을 유지하는 건 특히 이상함. 전체 권한 체계가 형식적이라는 느낌임

    • Apple은 예전 광고를 다시 봐야 함 (YouTube 링크)
    • 참고로 UAC는 보안 경계가 아님, 따라서 UAC-bypass는 권한 상승 취약점으로 취급되지 않음
    • 더 큰 문제는 여전히 많은 개발자가 “모든 것이 모든 것에 접근 가능”하다는 낡은 패러다임에 머물러 있다는 점임. macOS의 UX가 완벽하진 않지만, 무제한 접근이 기본값인 건 더 위험함
    • 게다가 Apple은 자사 앱에는 예외를 둠. 사용자 경험을 해치지 않기 위해서임
    • 이건 Mac의 sandbox가 아니라 TCC 시스템임. App Sandbox를 사용하는 앱은 Documents 접근 프롬프트조차 띄울 수 없음. 대신 Security Scoped Bookmark라는 방식으로 접근을 유지할 수 있음 (참고 링크)

  • tccutil reset 외에도 보안 설정에서 권한을 켰다가 끄는 방법으로도 초기화 가능함.
    UI가 버그로 인해 상태를 잘못 표시할 뿐 실제 권한은 정상 작동함.
    체크박스 색상도 포커스 여부에 따라 달라져 헷갈림. Sequoia 버전에서도 여전함.
    외장 드라이브에 설치된 게임들이 “removable volumes” 접근을 요청해 목록에 잔뜩 뜨는 것도 흥미로움

  • 이게 버그인지, 보안 취약점인지, 단순 실수인지 헷갈림. 모든 앱에 대해 reset 명령을 실행하는 게 좋을지 고민됨

    • 단순히 UI상의 누락임. 내부 시스템은 정상 작동 중임
    • 이런 건 보안 UI 버그로 분류됨. 사용자가 권한 상태를 인지하지 못하게 하므로 CVE 대상이 될 수도 있음
    • Apple의 형식적인 보안 절차와 실제 파일 접근 구조가 충돌하는 사례임. 설정에서 권한 상태를 명확히 보여주고, 해제 후 재부여를 어렵게 해야 함. 그리고 앱 재시작을 요구하는 권한은 이제 좀 없애야 함

  • 최신 macOS에서도 비슷한 보안 UI 혼란이 있음.
    “Full Disk Access” 항목에서 일부 앱이 회색으로 표시되는데, 켜진 상태와 꺼진 상태가 구분되지 않음.
    이게 버그인지, 실제로 권한이 있는 건지 알 수 없음

    • Apple의 설명이 모호함. “Files & Folders” 목록은 단순히 권한 요청 이력을 보여주는 것뿐임.
      Full Disk Access를 꺼도 일부 민감 폴더만 보호되고, 일반 폴더(Desktop, Documents 등)는 여전히 접근 가능함 (Apple 문서)

  • 문제의 원인은 Documents 폴더에 설정된 com.apple.macl 확장 속성 때문임. SIP로 인해 제거할 수 없음

    • 이는 버그가 아니라 두 보안 시스템의 UI 불일치임. 실제 보호는 작동하지만 UI가 이를 표현하지 못함

  • iOS에서도 같은 현상이 있을까 궁금함

    • iOS는 앱이 파일 선택기나 자체 폴더 외부에 접근할 수 없음, 따라서 동일한 문제는 발생하지 않음
답변달기