샌드박스에서 opt out, 일부러 그리고 그물을 갖고

"직접 배포 앱은 App-Sandbox 안 돼. Recall-해석 마운트-NAS 경로가 사용자 picker 없이 열리려면 필요해; 읽기 전용 처리, hardened runtime, 플러그인/헬퍼 없음, 엄격한 검증으로 보완해."

끄는 보호는 진지한 이유를 받을 자격이 있어

App Sandbox 는 macOS 의 제일 좋은 보호 중 하나야: 앱을 사용자가 명시적으로 건네는 파일로만 가둬. 그걸 끄는 건 어깨 으쓱이 아냐 — 이름 붙이고, 정당화하고, 보완해야 하는 보안 결정이야. Ashen Reel 은 opt out 하고, 이유는 앱의 목적 전체에 구워져 있어.

샌드박스는 사용자가 고른 scope 로 파일 접근을 줘: open panel, drag-drop, 저장된 북마크. 근데 Recall 딥링크는 사용자가 panel 에서 절대 안 고른 경로를 해석해 — 파일 다이얼로그가 아니라 자막 검색에서 왔어. 샌드박스된 앱은 그 경로에 대한 보안 scope 가 없어서 그냥 못 열어. 샌드박스 켜기는 앱이 제공하려고 존재하는 바로 그 handoff 를 깨. 그러니 opt-out 은 편의가 아냐; 핵심 기능의 값이야.

보호는 이름 붙은 이유랑 보완 컨트롤이 있을 때만 꺼. '샌드박스 껐어' 는 조용할 땐 위험 신호고, 적힌 이유랑 포기한 보호를 대체하는 게 뭔지 목록과 함께 올 땐 방어 가능한 엔지니어링 결정이야. opt-out 이랑 보완은 한 세트야.

샌드박스를 대체하는 것

샌드박스를 포기하는 게 안전을 포기하는 건 아냐 — 관련 보호를 손으로 다시 짓는다는 거야. Ashen Reel 의 보완 컨트롤은 구체적이야: 소스 미디어는 엄격히 읽기 전용으로 처리되고(Track 5), hardened runtime 이 켜진 채라 서명 안 된 코드가 주입 못 되고, 플러그인 없고, privileged helper 없고, 임의 쉘 없고, 공격할 listening 서비스 없고, 모든 Recall-해석 경로가 허용 루트에 대해 독립적으로 검증돼(Track 3). 샌드박스의 일은 폭발 반경을 제한하는 거였고; 이 컨트롤들이 다른 방식으로 걜 제한해.

tradeoff 가 못 숨게 적힌 posture:

생각 없는 opt-out 이 진짜 위험이야. 문제는 절대 'sandbox off' 자체가 아냐 — 자리에 아무것도 안 놓고 이유도 기록 안 한 'sandbox off' 야. 많은 앱이 경고를 없애려고 보호를 끄고 조용히 물렁한 타겟이 돼. 규율은 진짜 요구사항이 강제할 때만 opt out 하고, 없앤 모든 보호에 대해 코드베이스한테 보완 컨트롤을 빚지는 거야.

왜 이게 정직한 엔지니어링인가

tradeoff 를 숨기는 대신 이름 붙이는 데 진정성이 있어. Ashen Reel 은 샌드박스가 문제 아닌 척하거나, 왜인지 안 말하고 조용히 약한 앱을 낼 수도 있었어. 대신 아키텍처 문서가 opt-out 을 밝히고, 이유를 밝히고, 보완을 나열해 — 미래의 reader(미래의 너 포함)가 그 결정에 걸려 넘어지는 대신 감사할 수 있게. 읽고 이의 제기할 수 있는 보안 posture 가 그냥 이번 주에 우연히 참인 것보다 강해.

Code

entitlements posture — 숨기지 않고 명시된 tradeoff·text

Entitlements posture (a decision, written down):

  com.apple.security.app-sandbox                    = false  # opt OUT, on purpose
  hardened runtime (codesign --options runtime)      = ON     # keep other guards
  com.apple.security.cs.disable-library-validation   = false  # no unsigned code
  JIT / unsigned executable memory / dyld env overrides = none

WHY sandbox is off:
  A Recall deep link resolves a NAS path the user never picked in an open
  panel. A sandboxed app has no security scope for that path, so the core
  handoff cannot open the file. Sandbox on = the app's reason to exist, broken.

COMPENSATING CONTROLS (what replaces the sandbox's protection):
  - read-only media handling (Track 5): never writes the source
  - no plugins, no privileged helper, no arbitrary shell, no listening port
  - independent Recall-root + canonical-file validation (Track 3)
  - hardened runtime: still no unsigned code injection, no risky dyld env

Exercise

네 프로젝트가 끄거나 느슨하게 한 보안 기본값을 찾아 — 비활성 샌드박스, 느슨한 CORS 정책, 관대한 파일 권한, 건너뛴 인증서 검사, 'allow all' 방화벽 규칙. 그 하나에 대해 두 가지를 적어: opt-out 을 강제한 구체적 요구사항, 그리고 없앤 보호를 대체하는 구체적 보완 컨트롤. 둘 다 못 채우면, tradeoff 가 아니라 정당화 안 된 약점을 가진 거야.

Hint

방어 가능한 opt-out 은 항상 양쪽 반을 가져: 진짜 이유('핵심 기능이 그거 켜곤 문자 그대로 작동 못 함')랑 보완('대신 이게 폭발 반경을 제한함'). 이유가 '경고를 뱉어서' 고 보완 칸이 비면, 그건 엔지니어링 tradeoff 가 아냐 — 발견되길 기다리는 물렁한 타겟이야.

샌드박스에서 opt out, 일부러 그리고 그물을 갖고

끄는 보호는 진지한 이유를 받을 자격이 있어

샌드박스를 대체하는 것

왜 이게 정직한 엔지니어링인가

Code

External links

Exercise

Progress

댓글 0