# macOS의 Privacy & Security 설정을 신뢰할 수 없는 이유 > Clean Markdown view of GeekNews topic #28405. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28405](https://news.hada.io/topic?id=28405) - GeekNews Markdown: [https://news.hada.io/topic/28405.md](https://news.hada.io/topic/28405.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-11T09:53:47+09:00 - Updated: 2026-04-11T09:53:47+09:00 - Original source: [eclecticlight.co](https://eclecticlight.co/2026/04/10/why-you-cant-trust-privacy-security/) - Points: 1 - Comments: 1 ## Topic Body - 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` 명령으로만 삭제 가능 - 이로 인해 사용자는 **앱의 실제 접근 상태를 확인하거나 제어하기 어려운 상황**에 놓임 ## Comments ### Comment 55090 - Author: neo - Created: 2026-04-11T09:53:48+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47719602) - 내가 보기엔 단순한 문제 같음. 앱에 폴더 접근 권한을 주면 그 폴더 안의 파일에도 접근할 수 있는 건 당연한 일로 예상했음 - 문서를 자세히 읽어야 함. **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 링크](https://www.youtube.com/watch?v=8CwoluNRSSc)) - 참고로 UAC는 **보안 경계가 아님**, 따라서 UAC-bypass는 권한 상승 취약점으로 취급되지 않음 - 더 큰 문제는 여전히 많은 개발자가 “모든 것이 모든 것에 접근 가능”하다는 **낡은 패러다임**에 머물러 있다는 점임. macOS의 UX가 완벽하진 않지만, 무제한 접근이 기본값인 건 더 위험함 - 게다가 Apple은 **자사 앱에는 예외**를 둠. 사용자 경험을 해치지 않기 위해서임 - 이건 Mac의 sandbox가 아니라 **TCC 시스템**임. App Sandbox를 사용하는 앱은 Documents 접근 프롬프트조차 띄울 수 없음. 대신 **Security Scoped Bookmark**라는 방식으로 접근을 유지할 수 있음 ([참고 링크](https://www.mothersruin.com/software/Archaeology/reverse/boo...)) - `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 문서](https://support.apple.com/guide/security/controlling-app-acc...)) - 문제의 원인은 Documents 폴더에 설정된 **com.apple.macl 확장 속성** 때문임. SIP로 인해 제거할 수 없음 - 이는 버그가 아니라 **두 보안 시스템의 UI 불일치**임. 실제 보호는 작동하지만 UI가 이를 표현하지 못함 - iOS에서도 같은 현상이 있을까 궁금함 - iOS는 앱이 **파일 선택기나 자체 폴더 외부에 접근할 수 없음**, 따라서 동일한 문제는 발생하지 않음