Worker Executor و Lower-privilege Sandbox

1. مسئله: چرا اجرای Job با هویت Supervisor خطرناک است

Supervisor یک فرایند طولانی‌عمر با مسئولیت lifecycle است؛ Job payload یک واحد کوتاه‌عمر و متغیر. اگر Job با همان service identity، privilegeها و دسترسی‌های فایل/شبکه اجرا شود، مرز اعتماد عملاً حذف می‌شود. هدف این درس جداکردن هویت اجرا و effective authority از Supervisor است، نه صرفاً ساختن یک child process با نام متفاوت.

قانون پایه: requested authority، allowed authority و effective authority سه چیز جدا هستند. PASS فقط وقتی ممکن است که evidence نشان دهد authority واقعی executor از profile مجاز فراتر نرفته است.

2. مرز مالکیت درس و Non-goalها

LOC-007 فقط مرز Executor/Sandbox را مالک است. restart policy، watchdog و service lifecycle متعلق به LOC-006 است؛ envelope و version negotiation متعلق به LOC-008. همچنین sandbox هرگز اثبات نمی‌کند کد دلخواه «امن» است؛ فقط reachability و authority را محدود می‌کند.

در تصمیم‌گیری، هر ادعا باید به evidence همین مرز متصل باشد: executor identity، policy requested/allowed/effective، و result/termination record.

3. Job Contract حداقلی

Job Contract باید به‌جای «هر چیزی اجرا کن» یک درخواست محدود باشد: job type، input/output مشخص، timeout، resource limits، capabilityهای درخواستی و effect profile. این قرارداد نباید credential یا privilege اضافی را ضمنی به executor منتقل کند.

برای هر Job، requested_capabilities را صریح ثبت کن تا admission قبل از launch بتواند آن را با allowed_capabilities مقایسه کند.

4. Supervisor Identity در برابر Executor Identity

Executor باید تحت هویتی اجرا شود که authority آن از supervisor باریک‌تر باشد. تفاوت فقط username نیست؛ باید privilege drop و effective token/context هم بررسی شود. اگر executor همان identity و همان authority supervisor را به ارث ببرد، identity_state قابل قبول نیست.

در Windows، restricted token می‌تواند privilegeها را حذف و SIDها را deny-only یا restricted کند. در Linux/systemd، کاهش privilege و محدودیت‌های namespace/filesystem باید در effective state قابل مشاهده باشد.

5. Capability Admission: Requested ≤ Allowed

پیش از اجرای Job، capabilityهای درخواستی باید subset profile مجاز باشند. درخواست خارج از profile نباید با «فعلاً اجازه بده» یا widening پنهان حل شود.

نمونه: converter فقط read_input, write_output و resource-bounded execution می‌خواهد. اگر read_credentials یا spawn_arbitrary_children درخواست شود، تصمیم باید typed non-success باشد.

6. Filesystem Policy: Root خواندنی، Workspace نوشتنی

Policy فایل را با pathهای مشخص مدل کن: root یا application files خواندنی، workspace/output مجاز نوشتنی، credential store غیرقابل‌دسترسی و temp در فضای خصوصی. working directory متفاوت به‌تنهایی isolation نیست.

Failure Probe: اگر Job یک path خارج از workspace بخواهد، آن Job باید پیش از execution رد شود؛ sandbox نباید خودکار گسترده شود.

7. Process و Device Boundary

Child-process rule را صریح کن: deny، allowlist یا bounded helper. همچنین device access باید explicit باشد؛ نداشتن نیاز به GPU/USB/serial نباید به معنای دسترسی آزاد تلقی شود.

اگر Job به process-spawn نیاز ندارد، اجازه‌ی عمومی spawn یک authority اضافی است و باید policy_mismatch ایجاد کند.

8. Network Scope به‌عنوان Effect Profile

شبکه یک capability مستقل است. حالت پیش‌فرض برای Job بدون نیاز شبکه می‌تواند none باشد؛ در Transfer این درس فقط یک endpoint تاییدشده اضافه می‌شود. تغییر network rule نباید محدودیت filesystem، process یا secrets را تضعیف کند.

مهم: requested network policy اثبات effective network boundary نیست؛ باید effective profile یا test evidence ثبت شود.

9. Resource Envelope و Timeout

CPU، memory و wall timeout بخشی از sandbox profile هستند تا payload نتواند node را بی‌نهایت مصرف کند. Resource limit امنیت کامل نیست، ولی blast radius عملیاتی را کم می‌کند.

در نتیجه‌ی Job، termination reason باید بین completed، timeout، resource limit و executor failure قابل تفکیک باشد.

10. Secret Exposure و Environment Allowlist

Environment inheritance یکی از مسیرهای رایج نشت authority است. به‌جای انتقال کل environment supervisor، allowlist محدود بساز. credentialها، tokenها و مسیر secret store باید خارج از executor باشند مگر اینکه Job Contract به‌طور صریح و مجاز خلاف آن را ثابت کند.

Failure Probe: وجود supervisor-only secret در environment حتی با CPU/memory صحیح، تصمیم را از PASS خارج می‌کند.

11. Linux/systemd: Requested Setting با Effective Sandbox یکی نیست

systemd controls مانند NoNewPrivileges=, ProtectSystem= و PrivateTmp= ابزارهای مفید hardening هستند، اما اثربخشی برخی از آن‌ها به kernel/namespace/capability environment وابسته است. بنابراین configuration string را به‌تنهایی proof ندان.

اگر primitive لازم در platform profile unavailable باشد، state باید ISOLATION_UNAVAILABLE/DEFER بماند تا evidence موثر فراهم شود.

12. Windows Restricted Token: Primitive، نه کل Sandbox

Microsoft restricted token می‌تواند privilegeها را حذف کند، SID را deny-only کند و restricting SID اضافه کند. این یک primitive مهم است، اما به‌تنهایی filesystem policy، network scope، process-spawn rule یا resource limit را تعریف نمی‌کند.

Matrix باید restricted-token evidence را کنار بقیه dimensions نگه دارد، نه اینکه آن را برابر «sandbox کامل» بگیرد.

13. Result Envelope و Audit Evidence

نتیجه‌ی executor باید فقط exit code نباشد. حداقل شامل sandbox profile/version، effective capabilities، termination reason، result status و audit ref باشد. اگر policy requested با effective state فرق داشت، mismatch باید ثبت شود.

این record کمک می‌کند retry، incident review و recovery بر اساس evidence انجام شود، نه بر اساس «process اجرا شد».

14. Lab: Worker Executor Privilege & Sandbox Matrix v1

در Lab هشت fixture مصنوعی را بررسی می‌کنی. starter پاسخ را از قبل ندارد. باید identity، capability، isolation، filesystem، network/process، secret exposure، decision و reason را جدا محاسبه کنی.

موارد منفی شامل path خارج از workspace، primitive unavailable، secret exposure، capability widening، effective-authority widening و reuse supervisor identity هستند. هیچ privilege واقعی سیستم تغییر نمی‌کند.

15. Transfer و معیار خروج

Transfer: یک Job جدید فقط نیاز به outbound access به api.example.test:443 دارد. network allowance را محدود و مشخص اضافه کن، ولی credential store همچنان deny، arbitrary child process همچنان deny، workspace همان قبلی و executor identity همچنان lower-privilege بماند.

خروج موفق یعنی بتوانی Worker Executor Privilege & Sandbox Matrix v1 را از evidence بسازی و توضیح بدهی چرا requested policy یا packet/configuration به‌تنهایی proof effective authority نیست.