Windows ನಲ್ಲಿ Codex ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಸುರಕ್ಷಿತ, ಪರಿಣಾಮಕಾರಿ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ನಿರ್ಮಿಸುವುದು

ನಾನು 2025ರ ಸೆಪ್ಟೆಂಬರ್‌ನಲ್ಲಿ Codex ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಕ್ಕೆ ಸೇರಿದಾಗ, Windows ಗಾಗಿ Codex ನಲ್ಲಿ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನುಷ್ಠಾನ ಇರಲಿಲ್ಲ. ಅದರರ್ಥ, OpenAI ಯ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ಬಳಸುವಾಗ Windows ಬಳಕೆದಾರರು ಎರಡು ದುರ್ಬಲ ಆಯ್ಕೆಗಳ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗುತ್ತಿತ್ತು:

1. ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಚಾಲನೆಗೊಳಿಸಲು ಬಯಸಿದ ಬಹುತೇಕ ಪ್ರತಿಯೊಂದು ಕಮಾಂಡ್‌ಗೂ (ಓದುವುದಕ್ಕೂ ಸಹ) ಅನುಮೋದನೆ ನೀಡುವುದು. ಇದು ಅಸಮರ್ಥವೂ ಕಿರಿಕಿರಿಯೂ ಆಗಿದೆ. Codex ಅನ್ನು ಬಳಸುವ ಪ್ರಮುಖ ಪ್ರಯೋಜನವೆಂದರೆ, ಎಲ್ಲಾ ಬೇಸರದ ಕೆಲಸವನ್ನು ನೀವೇ ಮಾಡಬೇಕಾಗಿಲ್ಲ.
2. ಪೂರ್ಣ ಪ್ರವೇಶ ಮೋಡ್ ಸಕ್ರಿಯಗೊಳಿಸುವುದು: ಅನುಮೋದನೆ ಅಥವಾ ನಿರ್ಬಂಧಗಳಿಲ್ಲದೆ Codex ಎಲ್ಲಾ ಕಮಾಂಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಬಿಡುವುದು. ಇದರಿಂದ ಅಡೆತಡೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ, ಆದರೆ ಮೇಲ್ವಿಚಾರಣೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ.

Codex⁠, ನಮ್ಮ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್, ಡೆವಲಪರ್ ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗಳಲ್ಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ—ಅದು CLI ಆಗಿರಲಿ, IDE ಎಕ್ಸ್ಟೆನ್ಷನ್ ಆಗಿರಲಿ ಅಥವಾ ಡೆಸ್ಕ್‌ಟಾಪ್ ಆಪ್ ಆಗಿರಲಿ. ಇದು ಇನ್ಫರೆನ್ಸ್ ನಿರ್ವಹಿಸಲು ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಮಾಡೆಲ್ ಮತ್ತು ಕೀಬೋರ್ಡ್ ಬಳಿ ಇರುವ ಮಾನವನ ನಡುವೆ ಸಂಭಾಷಣೆಯನ್ನು ವ್ಯವಸ್ಥಿತಗೊಳಿಸುತ್ತದೆ.

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ Codex ನಿಜವಾದ ಬಳಕೆದಾರರ ಅನುಮತಿಗಳೊಂದಿಗೇ ನಡೆಯುತ್ತದೆ. ಅಂದರೆ, ಬಳಕೆದಾರನು ಮಾಡಬಲ್ಲದ್ದನ್ನೆಲ್ಲ ಅದು ಮಾಡಬಹುದು. ಇದು ಶಕ್ತಿಶಾಲಿಯೂ, ಸಂಭವನೀಯವಾಗಿ ಅಪಾಯಕಾರಿಯೂ ಆಗಿದೆ. ಕೋಡಿಂಗ್ ಮಾಡೆಲ್ ಸ್ಥಳೀಯವಾಗಿ ಕಮಾಂಡ್‌ಗಳನ್ನು ಚಾಲನೆಗೊಳಿಸಲು harness ಗೆ ಹೇಳಬಹುದು—ಪರೀಕ್ಷೆಗಳನ್ನು ಓಡಿಸುವುದರಿಂದ ಹಿಡಿದು, ಫೈಲ್ ಓದುವುದು ಅಥವಾ ಸಂಪಾದಿಸುವುದು, Git ಬ್ರಾಂಚ್ ರಚಿಸುವುದರವರೆಗೆ. ಆದ್ದರಿಂದ Codex ನ ಡೀಫಾಲ್ಟ್ ಮೋಡ್ ಪರಿಣಾಮಕಾರಿತ್ವ ಮತ್ತು ಸುರಕ್ಷತೆ ನಡುವೆ ಸರಿಯಾದ ಸಮತೋಲನ ಕಂಡುಹಿಡಿಯಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಈ ಡೀಫಾಲ್ಟ್ ಮೋಡ್ Codex ಗೆ ಬಹುತೇಕ ಎಲ್ಲೆಡೆಯಿಂದ ಫೈಲ್‌ಗಳನ್ನು ಓದಲು ಮತ್ತು ನಿಮ್ಮ ವರ್ಕ್‌ಸ್ಪೇಸ್ ಒಳಗೆ (ಅಂದರೆ, ನೀವು Codex ಚಲಾಯಿಸುತ್ತಿರುವ ಡೈರೆಕ್ಟರಿ) ಫೈಲ್‌ಗಳನ್ನು ಬರೆಯಲು ಅವಕಾಶ ಮಾಡುತ್ತದೆ. ನೀವು ಬಯಸುವುದಾಗಿ ಸೂಚಿಸದ ಹೊರತು ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶವಿರುವುದಿಲ್ಲ. ಫೈಲ್‌ಗಳನ್ನು ಬರೆಯುವುದು ಮತ್ತು ಸುರಕ್ಷಿತ ಮಿತಿಗಳೊಳಗೆ ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶಿಸುವುದಕ್ಕೆ ಈ ಸ್ವಯಂ ನಿಯಂತ್ರಣ ಸಾಧಿಸಲು, Codex ಗೆ ಈ ನಿಯಂತ್ರಣಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಜಾರಿಗೊಳಿಸುವ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಪರಿಸರ ಬೇಕಾಗುತ್ತದೆ.

ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಒಂದು ನಿರ್ಬಂಧಿತ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪರಿಸರವಾಗಿದೆ. ಡೆವಲಪರ್ Codex ಬಳಸಿದಾಗ, ಅವರ ಕಂಪ್ಯೂಟರ್‌ನ ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆ ಕಡಿತಗೊಳಿಸಿದ ಅನುಮತಿಗಳೊಂದಿಗೆ ಒಂದು ಕಮಾಂಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಆ ನಿರ್ಬಂಧಗಳು ಪ್ರಕ್ರಿಯೆ ಮರದೊಳಗೆ ಕೆಳಗೆ ಹರಡುತ್ತವೆ. ಪ್ರತಿ Codex ಕಮಾಂಡ್ ಆರಂಭದಿಂದಲೇ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟಿರುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಸಂತತಿ ಪ್ರಕ್ರಿಯೆಯೂ ಅದೇ ಗಡಿಯೊಳಗೆ ಉಳಿಯುತ್ತದೆ.

ಪರಿಣಾಮಕಾರಿ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸಲು Codex ಗೆ ಕಂಪ್ಯೂಟರ್‌ನ ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಯಿಂದ ಜಾರಿಗೊಳ್ಳುವ ಪ್ರತ್ಯೇಕೀಕರಣ ವೈಶಿಷ್ಟ್ಯಗಳು ಅಗತ್ಯ. ಕೆಲವು ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಗಳು ಇದನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡುವ ಉಪಯುಕ್ತಿಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ (ಉದಾ., MacOs ನಲ್ಲಿ Seatbelt, Linux ನಲ್ಲಿ seccomp ಅಥವಾ bubblewrap). ಆದರೆ, Windows ಇಂತಹ ಸಾಮರ್ಥ್ಯವನ್ನು ಈಗಾಗಲೇ ಸಿದ್ಧವಾಗಿ ಒದಗಿಸುವುದಿಲ್ಲ.

Codex ಅನ್ನು Windows ಮೇಲೆಯೂ ಈಗಾಗಲೇ ಇತರ ಎಲ್ಲೆಡೆ ಇರುವಷ್ಟೇ ಸುರಕ್ಷಿತವಾಗಿ ಮತ್ತು ಆನಂದಕರವಾಗಿ ಬಳಸಲು, ನಮ್ಮದೇ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸಬೇಕಾಯಿತು.

Windows ಪ್ರತ್ಯೇಕೀಕರಣಕ್ಕಾಗಿ ಕೆಲವು ಉಪಕರಣಗಳು ಮತ್ತು ಮೂಲಾಂಶಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಒಂದೂ ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪೂರೈಸದಿದ್ದರೂ, ನಾವು ಹಲವಾರು ಸಾಧ್ಯ ಪರಿಹಾರಗಳನ್ನು ಪರಿಶೀಲಿಸಿದೆವು—ವಿಶೇಷವಾಗಿ AppContainer, Windows Sandbox ಮತ್ತು Mandatory Integrity Control ಲೇಬಲಿಂಗ್.

ಆಪ್‌ಕಂಟೇನರ್

• ಏನು: AppContainer Windows ನ ಸ್ವದೇಶಿ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಆಗಿದ್ದು, ಮುಂಚಿತವಾಗಿಯೇ ತಮಗೆ ಯಾವ ಪ್ರವೇಶ ಬೇಕು ಎಂದು ನಿಖರವಾಗಿ ತಿಳಿದಿರುವ ಆಪ್‌ಗಳಿಗಾಗಿ ನಿರ್ಮಿಸಲಾದ ಸಾಮರ್ಥ್ಯಾಧಾರಿತ ಪ್ರತ್ಯೇಕೀಕರಣ ಮಾಡೆಲ್ ಆಗಿದೆ.
• ಏಕೆ: ಕೇವಲ best-effort ನಿರ್ಬಂಧಗಳ ಬದಲು ನಿಜವಾದ OS ಗಡಿಯನ್ನು ನೀಡುವುದರಿಂದ ಆಕರ್ಷಕವಾಗಿತ್ತು.
• ಏಕೆ ಇಲ್ಲ: Codex ಕಟ್ಟುನಿಟ್ಟಾಗಿ ವ್ಯಾಪ್ತಿ ನಿಗದಿಪಡಿಸಲಾದ ಒಂದೇ ಆಪ್ ಅಲ್ಲ. ಇದು ಮುಕ್ತ-ಅಂತ್ಯದ ಡೆವಲಪರ್ ಕಾರ್ಯಪ್ರವಾಹಗಳನ್ನು ಚಾಲಿತಗೊಳಿಸುತ್ತದೆ: ಶೆಲ್‌ಗಳು, Git, Python, ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳು, ಬಿಲ್ಡ್ ಟೂಲ್‌ಗಳು ಮತ್ತು ಏಜೆಂಟ್‌ಗೆ ಅಗತ್ಯವೆಂದು ಅದು ನಿರ್ಧರಿಸುವ ಯಾವುದೇ ಇತರ ಬೈನರಿಗಳು. ವಾಸ್ತವದಲ್ಲಿ, ಅದರಿಂದ AppContainer ಆ ಸಮಸ್ಯೆಗೆ ಸರಿಹೊಂದದ ರೂಪದ್ದಾಯಿತು. ಅದು ಬಲವಾದ ಪ್ರತ್ಯೇಕೀಕರಣವಾಗಿತ್ತು, ಆದರೆ “ಒಂದು ಏಜೆಂಟ್ ಡೆವಲಪರ್‌ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಬಿಡುವುದು” ಎಂಬುದಕ್ಕಿಂತ ಬಹಳ ಕಿರಿದಾದ ವರ್ಗದ ಕಾರ್ಯಭಾರಗಳಿಗೆ ಮಾತ್ರ.

Windows Sandbox

• ಏನು: Windows Sandbox ಎನ್ನುವುದು Microsoft‌ನ ಬಳಸಿ ತ್ಯಜಿಸಬಹುದಾದ ಹಗುರವಾದ VM ಆಗಿದೆ. ನಿಮಗೆ ಬಲವಾದ ಪ್ರತ್ಯೇಕೀಕರಣ ಗಡಿಯೊಂದಿಗೆ ಹೊಸ Windows ಡೆಸ್ಕ್‌ಟಾಪ್ ಸಿಗುತ್ತದೆ ಮತ್ತು ಅದರೊಳಗೆ ನೀವು ಏನು ಮಾಡಿದರೂ ಸೆಷನ್ ಮುಗಿದಾಗ ಅಳಿದುಹೋಗುತ್ತದೆ.
• ಏಕೆ: ಸ್ಪಷ್ಟ ಕಾರಣಗಳಿಗಾಗಿ ಆಸಕ್ತಿದಾಯಕ—AppContainer ಗಿಂತ ಇಚ್ಛೆಯಾದ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ತುಂಬಾ ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವದು ಮತ್ತು ಭದ್ರತಾ ದೃಷ್ಟಿಯಿಂದ ಬಹಳ ಬಲವಾದ ಆವರಣ.
• ಏಕೆ ಇಲ್ಲ: Codex ಬಳಕೆದಾರನ ನಿಜವಾದ checkout, tools ಮತ್ತು environment ಮೇಲೆಯೇ ನೇರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕಾಗಿದೆ; ಪ್ರತ್ಯೇಕ throwaway desktop ಒಳಗೆ ಅಲ್ಲ, ಅದಕ್ಕೆ setup ಮತ್ತು host/guest bridging ಬೇಕಾಗುತ್ತಿತ್ತು. ಇದಕ್ಕೂ ಒಂದು ಮೂಲಭೂತ ಉತ್ಪನ್ನ ಸಮಸ್ಯೆ ಇತ್ತು: Windows Sandbox, Windows Home SKUಗಳಲ್ಲಿಯೂ ಸಹ ಲಭ್ಯವಿಲ್ಲ.

ಮ್ಯಾಂಡೇಟರಿ ಇಂಟೆಗ್ರಿಟಿ ಕಂಟ್ರೋಲ್ (MIC) ಇಂಟೆಗ್ರಿಟಿ ಲೇಬಲಿಂಗ್

• ಏನು: Windows “ಸಮಗ್ರತೆ ಮಟ್ಟಗಳು” ಎಂದು ಕರೆಯಲ್ಪಡುವ ಪರಿಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿದೆ, ಉದಾಹರಣೆಗೆ ಕಡಿಮೆ, ಮಧ್ಯಮ ಮತ್ತು ಹೆಚ್ಚು, ಇವು ವಸ್ತುಗಳು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸಿಸ್ಟಂ ಎಷ್ಟು ನಂಬುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಮೂಲಭೂತ ನಿಯಮವೆಂದರೆ, ಸಾಮಾನ್ಯ ACL ಅದನ್ನು ಅನುಮತಿಸಿದರೂ ಸಹ, ಕಡಿಮೆ-ಸಮಗ್ರತೆಯ ಪ್ರಕ್ರಿಯೆಯು ಹೆಚ್ಚು ಸಮಗ್ರತೆ ಮಟ್ಟದ ವಸ್ತುವಿಗೆ ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಕಡಿಮೆ-ಸಮಗ್ರತೆಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕಡಿಮೆ ವಿಶ್ವಾಸಾರ್ಹವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಆ ವಸ್ತುಗಳನ್ನು ಅದಕ್ಕೆ ಅನುಮತಿಸಲು ಸ್ಪಷ್ಟವಾಗಿ ಮರು-ಲೇಬಲ್ ಮಾಡಲಾಗಿದ್ದರೆ ಮಾತ್ರ ಹೊರತುಪಡಿಸಿ, ಸಾಮಾನ್ಯ ಮಧ್ಯಮ-ಸಮಗ್ರತೆಯ ವಸ್ತುಗಳಿಗೆ ಬರೆಯುವುದನ್ನು Windows ನಿರ್ಬಂಧಿಸುತ್ತದೆ.
• ಏಕೆ: MIC ಕಾಗದದ ಮೇಲೆ ಸೊಗಸಾಗಿ ಕಾಣುತ್ತದೆ - ಕಡಿಮೆ ಸಮಗ್ರತೆಯಲ್ಲಿ Codex ಅನ್ನು ರನ್ ಮಾಡಿ, ಬರೆಯಬಹುದಾದ ಬೇರುಗಳನ್ನು ಕಡಿಮೆ ಸಮಗ್ರತೆ ಎಂದು ಮರುಲೇಬಲ್ ಮಾಡಿ ಮತ್ತು ವಿಂಡೋಸ್ ಎಲ್ಲೆಡೆ ಬರೆಯಬಾರದು ಎಂದು ಜಾರಿಗೊಳಿಸಲು ಬಿಡಿ. ಅದು ನಮಗೆ ಅಡ್ಮಿನ್‌ ಅಗತ್ಯವಿಲ್ಲದ, ನಿಜವಾದ OS ಯಾಂತ್ರಿಕತೆಯಿಂದ ಬೆಂಬಲಿತವಾದ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತಿತ್ತು.
• ಏಕೆ ಬೇಡ: ACLಗಳಂತೆ, ಸಮಗ್ರತಾ ಲೇಬಲ್‌ಗಳು ನಿಜವಾದ ಹೋಸ್ಟ್ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುತ್ತವೆ ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅರ್ಥಾತ್ಮಕ ಬದಲಾವಣೆ ವಿಶೇಷವಾಗಿ ವ್ಯಾಪಕವಾಗಿದೆ. ವರ್ಕ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಕಡಿಮೆ ಇಂಟೆಗ್ರಿಟಿ ಎಂದು ಗುರುತಿಸುವುದರಿಂದ ಕೇವಲ “Codex ಇಲ್ಲಿ ಬರೆಯಬಹುದು” ಎಂದಷ್ಟೇ ಅರ್ಥವಲ್ಲ. ಇದರ ಅರ್ಥ ಕಡಿಮೆ-ಸಮಗ್ರತೆಯ ಪ್ರಕ್ರಿಯೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಲಿ ಬರೆಯಬಹುದು. ನಿಜವಾದ ಡೆವಲಪರ್ ಯಂತ್ರದಲ್ಲಿ, ಅದು ಬಳಕೆದಾರರ ನಿಜವಾದ ಚೆಕ್‌ಔಟ್ ಅನ್ನು ಹೋಸ್ಟ್‌ಗಾಗಿ ಕಡಿಮೆ-ಸಮಗ್ರತೆಯ ಸಿಂಕ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ; ಇದು ಒಂದು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ವಿನ್ಯಾಸಕ್ಕೆ ಎಚ್ಚರಿಕೆಯಿಂದ ಗುರಿಗೊಳಿಸಿದ ACLಗಳನ್ನು ನೀಡುವುದಕ್ಕಿಂತ ಬಹಳ ಹೆಚ್ಚು ಅಪಾಯಕಾರಿಯಾಗಿದೆ. ಮಧ್ಯಮ-ಸಮಗ್ರತೆಯ ಡೆವಲಪರ್ ಪರಿಕರಗಳು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಿದರೂ ಸಹ, ವರ್ಕ್‌ಸ್ಪೇಸ್‌ನ ಆಧಾರಭೂತ ನಂಬಿಕೆ ಮಾಡೆಲ್ ನಿಯಂತ್ರಿಸಲು ಕಷ್ಟವಾಗುವ ಮತ್ತು ಸಮರ್ಥಿಸಲು ಇನ್ನೂ ಕಷ್ಟವಾಗುವ ರೀತಿಯಲ್ಲಿ ಬದಲಾಗಿದೆ.

ಈ ಎಲ್ಲ ಆಯ್ಕೆಗಳು ಆರಂಭಿಸಲು ಸಹ ಸರಿಯಾಗಿಲ್ಲವೆಂದು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದ ನಂತರ, Windows ಬಳಕೆದಾರರಿಗೆ ಉತ್ತಮ Codex ಅನುಭವ ತರುವ ನಮ್ಮದೇ ಪರಿಹಾರವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು ಆರಂಭಿಸಿದೆವು.

ನಮಗೆ ಅಗತ್ಯವಿದ್ದ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಲು, ನಮ್ಮ ಮೊದಲ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೂಲಮಾದರಿಯು Windows ಪರಿಕಲ್ಪನೆಗಳು ಮತ್ತು ಸಾಧನಗಳ ಸಂಯೋಜನೆಯನ್ನು ಬಳಸಿತು. ಆರಂಭದಿಂದಲೇ, ಇದನ್ನು ಉನ್ನತೀಕರಣ ಅಗತ್ಯವಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುವುದು ಒಂದು ಗುರಿಯಾಗಿತ್ತು; ಅಂದರೆ, ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಸೆಟ್ ಅಪ್ ಮಾಡಲು ಅಥವಾ ರನ್ ಮಾಡಲು ಮಾತ್ರ Codex ಬಳಕೆದಾರರನ್ನು ನಿರ್ವಾಹಕ ಸೌಲಭ್ಯಗಳಿಗಾಗಿ ಪ್ರಾಂಪ್ಟ್ ಮಾಡುವ ಅಗತ್ಯವಿರಬಾರದು. ಅದರರ್ಥ ಎರಡು ವಿಷಯಗಳ ಮೇಲೆ ಸಮಂಜಸವಾದ ಮಿತಿಗಳನ್ನು ಹೇಗೆ ವಿಧಿಸಬೇಕು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದಾಗಿತ್ತು: ಫೈಲ್ ಬರವಣಿಗೆ ಕಾರ್ಯಗಳು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶ.

ನಾವು ಫೈಲ್ ಬರಹಗಳನ್ನು ಒಂದೂ ನಿಯಂತ್ರಿಸದಿದ್ದರೆ ಭದ್ರತಾ ಸಮಸ್ಯೆ ಉಂಟಾಗುತ್ತಿತ್ತು. ತುಂಬಾ ಕಠಿಣವಾಗಿ ನಿಯಂತ್ರಿಸಿದರೆ, ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಬಳಕೆದಾರರ ಉತ್ಪಾದಕತೆಯನ್ನು ಹಾಳುಮಾಡಿ ನಿರಂತರ ಅನುಮೋದನೆ ಕೇಳಬೇಕಾಗುತ್ತಿತ್ತು. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು Windows ನ ಎರಡು ಮುಖ್ಯ ಕಟ್ಟಡ ಬ್ಲಾಕ್‌ಗಳಾದ SID ಗಳು ಮತ್ತು write-restricted ಟೋಕನ್ ಗಳನ್ನು ಅವಲಂಬಿಸಿದೆವು.

SID ಅಥವಾ ಭದ್ರತಾ ಗುರುತಿಸುವಿಕೆ, Windows ಅನುಮತಿಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಗುರುತಾಗಿದೆ. ಪ್ರತಿ ಬಳಕೆದಾರನಿಗೂ SID ಇರುತ್ತದೆ, ಗುಂಪುಗಳಿಗೆ SIDs ಇರುತ್ತವೆ ಮತ್ತು ಒಂದೇ ಲಾಗಿನ್ ಸೆಷನ್‌ಗೂ ತನ್ನದೇ ಆದ SID ಸಿಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಪ್ರಸ್ತುತ ಲಾಗ್ ಇನ್ ಆಗಿರುವ ಸೆಷನ್‌ಗೆ S-1-5-5-X-Y ನಂತಹ SID ಇರಬಹುದು. ಸ್ಥಳೀಯ ನಿರ್ವಾಹಕರ ಗುಂಪಿಗೆ ನಿಯೋಜಿಸಲಾದ SID S-1-5-32-544 ಆಗಿರಬಹುದು.

Windows ನಿಜವಾದ ಬಳಕೆದಾರನಿಗೆ ಹೊಂದಿಕೆಯಾಗದ ಸಿಂಥೆಟಿಕ್ SID ಗಳನ್ನೂ ಸೃಷ್ಟಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ, ಆದರೆ ಅವು ACL ಗಳಲ್ಲಿ (access control list) ಕಾಣಿಸಬಹುದು; ಇವೇ ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಅಥವಾ ಡೈರೆಕ್ಟರಿಯನ್ನು ಯಾರು ಓದಬಹುದು/ಬರೆಯಬಹುದು/ಚಲಾಯಿಸಬಹುದು ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ. ಇದರಿಂದ SID ಗಳು ನಮ್ಮ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗೆ ಉಪಯುಕ್ತ ಮೂಲಾಂಶವಾಗುತ್ತವೆ: ನಾವು ಯಂತ್ರದ ಬೇರೆ ಯಾವುದನ್ನೂ ಅಡ್ಡಿಪಡಿಸದೇ, Codex ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಬಳಕೆಗೆ ಮಾತ್ರವಾದ SID ಗಳನ್ನು ಸೃಷ್ಟಿಸಬಹುದು

ಪ್ರಕ್ರಿಯಾ ಟೋಕನ್‌ಗಳು Windows ನಲ್ಲಿ ಭದ್ರತಾ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಾಗಿದ್ದು, ಅವು ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಗೆ ಗುರುತು ಮತ್ತು ವಿಶೇಷಾಧಿಕಾರಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ. ಒಂದು ಪ್ರಕ್ರಿಯೆ ಯಾವ ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸಬಹುದು ಎಂಬುದನ್ನು ಅವು ನಿರ್ಧರಿಸುತ್ತವೆ. ಬರವಣಿಗೆ-ನಿರ್ಬಂಧಿತ ಟೋಕನ್ ಎಂಬುದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಕಾರದ ಪ್ರಕ್ರಿಯೆ ಟೋಕನ್ ಆಗಿದ್ದು, ಬರವಣಿಗೆ ಕಾರ್ಯಾಚರಣೆಗಳ ಮೇಲೆ Windows ಹೆಚ್ಚುವರಿ ಪ್ರವೇಶ ಪರಿಶೀಲನೆಯನ್ನು ನಿರ್ವಹಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.

ಒಂದು ಬರಹ ಯಶಸ್ವಿಯಾಗಲು, ಎರಡು ಪರಿಶೀಲನೆಗಳೂ ಪಾಸ್ ಆಗಬೇಕು:

1. ಸಾಮಾನ್ಯ ಬಳಕೆದಾರ ಗುರುತು (ಟೋಕನ್ “ಮಾಲೀಕರು”) ಅದನ್ನು ಮಾಡಲು ಅನುಮತಿಸಲ್ಪಟ್ಟಿರಬೇಕು
2. ಟೋಕನ್‌ನ ನಿರ್ಬಂಧಿತ SID ಪಟ್ಟಿಯಲ್ಲಿರುವ ಕನಿಷ್ಠ ಒಂದು SID ಗಿಗೂ ಪ್ರವೇಶ ನೀಡಲ್ಪಟ್ಟಿರಬೇಕು

ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಈ ಪರಿಶೀಲನೆಗಳು ಫೈಲ್ ಸಿಸ್ಟಂನಲ್ಲಿ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಎಲ್ಲೆಲ್ಲಿ ಬದಲಾವಣೆ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ACL ಗಳ ಮೂಲಕ ನಿಖರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲು ಅವಕಾಶ ನೀಡಿದವು; ಇದರಿಂದ ಬರಹ ಕಾರ್ಯಾಚರಣೆಗಳ ಸುತ್ತಲಿನ ನಮಗೆ ಬೇಕಾದ ವಿವರಗಳು ಸಿಕ್ಕವು.

SID ಗಳು ಮತ್ತು write-restricted ಟೋಕನ್ ಗಳೊಂದಿಗೆ, ನಮ್ಮ ಏರದ sandbox ಹೀಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು:

1. ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸೆಟಪ್ sandbox-write ಎನ್ನುವ ಸಿಂಥೆಟಿಕ್ SID ಅನ್ನು ಸೃಷ್ಟಿಸಿತು.
2. sandbox-write SID ಗೆ ಬರೆಯುವ, ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮತ್ತು ಅಳಿಸುವ ಪ್ರವೇಶವನ್ನು ನೀಡಲಾಗಿದೆ
   1. ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿ
   2. config.toml ನಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ writable_roots .
3. ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸೆಟಪ್ ಅದೇ SID ಗೆ “writable ಒಳಗಿನ read-only” ಸ್ಥಳಗಳಿಗೆ ಬರಹ ಪ್ರವೇಶವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರಾಕರಿಸಿತು; ಉದಾಹರಣೆಗೆ:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex ಕಮಾಂಡ್‌ಗಳನ್ನು ಒಂದು write-restricted ಟೋಕನ್ ಅಡಿಯಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿತು; ಅದರ restricted SID ಪಟ್ಟಿಯಲ್ಲಿ ಎಲ್ಲರೂ, ಪ್ರಸ್ತುತ ಲಾಗಿನ್ ಆಗಿರುವ ಸೆಶನ್ SID ಮತ್ತು sandbox-write ಸಿಂಥೆಟಿಕ್ SID ಸೇರಿವೆ.

ಈ ಕ್ರಮವು ಫೈಲ್ ಬರಹಗಳನ್ನು ನಿಯಂತ್ರಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಪರಿಹರಿಸಿತು ಮತ್ತು ಆಶಾದಾಯಕವಾಗಿ ತೋರುತ್ತಿತ್ತು. ಈಗ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸಲು ನಮಗೆ ಪರಿಹಾರ ಬೇಕಿತ್ತು.

ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸುವುದು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನ ಮಹತ್ವದ ಭಾಗ. ಅದು ಇಲ್ಲದಿದ್ದರೆ, ದುರುದ್ದೇಶಿತ ಕೋಡ್ ಯಂತ್ರದಿಂದ ಡೇಟಾವನ್ನು ಇಂಟರ್ನೆಟ್‌ಗೆ ಸೋರಿಸಬಹುದು. ನಾವು elevation ಅಗತ್ಯ ತಪ್ಪಿಸಲು ಬಯಸಿದ್ದರಿಂದ, ನೆಟ್‌ವರ್ಕ್ ಸಂಚಾರವನ್ನು ಬಲವಾಗಿ ತಡೆಯಲು ನಮಗೆ ಸೀಮಿತ ಆಯ್ಕೆಗಳಷ್ಟೇ ಇವೆ. Windows Firewall ಹಾಗಿನ ನಾವು ಬಳಸಬೇಕೆಂದಿದ್ದ ಉಪಕರಣಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಆಡ್ಮಿನ್ ಅನುಮತಿಗಳಿಲ್ಲದೆ ಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಿರಲಿಲ್ಲ.

Windows Firewall ಆಯ್ಕೆಯಾಗಿ ಇಲ್ಲದ ಕಾರಣ, ನಾವು ನಿಯಂತ್ರಿಸಬಹುದಾದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮಿತಿಗೊಳಿಸಿದ್ದೇವೆ. ಡೆವಲಪರ್‌ಗಳು ನಿಜವಾಗಿಯೂ ಬಳಸುವ ವಿಧದ ನೆಟ್‌ವರ್ಕ್ ಆಧಾರಿತ ಟೂಲ್‌ಗಳಿಗಾಗಿ ಚೈಲ್ಡ್ ಪರಿಸರವನ್ನು ವಿಫಲವಾದಾಗ ಮುಚ್ಚಿದ ಸ್ಥಿತಿಯಲ್ಲಿ (fail-closed) ಇರಿಸಲು ನಾವು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ; ಇದರಿಂದ Git ಕಮಾಂಡ್‌ಗಳು, ಪ್ಯಾಕೇಜ್ ಇನ್‌ಸ್ಟಾಲರ್‌ಗಳು ಇತ್ಯಾದಿಗಳು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು ಇಂಟರ್‌ನೆಟ್‌ಗೆ ಸಂಪರ್ಕಿಸುವ ಯಾವುದೇ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಬಳಕೆದಾರರು ಅನುಮೋದನೆ ನೀಡಬೇಕಾಗುತ್ತದೆ. ಸ್ಪಷ್ಟ ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ಮಾರ್ಗಗಳನ್ನು ನಿಷ್ಪ್ರಯೋಜಕಗೊಳಿಸುವುದೇ ಆಲೋಚನೆಯಾಗಿತ್ತು: ಪ್ರಾಕ್ಸಿ-ಅವೇರ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕಾರ್ಯನಿರ್ವಹಿಸದ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಕಳುಹಿಸುವುದು, Git‌ನ HTTP(S) ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಕೂಡ ಅದೇ ರೀತಿ ಮಾಡುವಂತೆ ಮಾಡುವುದು ಮತ್ತು SSH ಮೂಲಕ Git ತಕ್ಷಣವೇ ವಿಫಲಗೊಳ್ಳುವಂತೆ ಮಾಡುವುದು. ಅದರ ಜೊತೆಗೆ, ನಾವು ಸಣ್ಣ denybin ಡೈರೆಕ್ಟರಿಯನ್ನು PATH‌ನ ಆರಂಭಕ್ಕೆ ಸೇರಿಸಿದ್ದೇವೆ ಮತ್ತು PATHEXT ಅನ್ನು ಮರುಕ್ರಮಗೊಳಿಸಿದ್ದೇವೆ, ಇದರಿಂದ ಸ್ಟಬ್ SSH ಮತ್ತು SCP ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ನಿಜವಾದ ಬೈನರಿಗಳಿಗಿಂತ ಮೊದಲು ರಿಸಾಲ್ವ್ ಆಗುತ್ತವೆ.

ಉದಾಹರಣೆಗೆ, ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸಲು ನಾವು ಬಳಸಿದ ಕೆಲವು ನಿರ್ದಿಷ್ಟ environment override ಗಳು ಇಲ್ಲಿವೆ:

• HTTPS_PROXY=http://127.0.0.1:9
• ALL_PROXY=http://127.0.0.1:9
• GIT_HTTPS_PROXY=http://127.0.0.1:9
• NO_PROXY=localhost,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

ಇದರಿಂದ ಅನೇಕ ಸಾಮಾನ್ಯ ಸಾಧನ-ಚಾಲಿತ ಟ್ರಾಫಿಕ್ ಹಿಡಿಯಲ್ಪಟ್ಟಿತು, ಆದರೆ ಅದು ಇನ್ನೂ ಸಲಹಾತ್ಮಕ ಮಟ್ಟದಲ್ಲೇ ಇತ್ತು. ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆ ವಾತವಾರಣವನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು, PATH ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಬಹುದು ಅಥವಾ ನೇರವಾಗಿ ಸಾಕೆಟ್ ತೆರೆಯಬಹುದು—ಇದು ತುಂಬಾ ಅಪಾಯಕರ.

ಯಾವುದೇ ಆಸಕ್ತಿದಾಯಕ ಸಾಫ್ಟ್‌ವೇರ್ ಅನುಷ್ಠಾನದಂತೆಯೇ, ಮೊದಲ ಮೂಲಮಾದರಿಗೂ ಕೆಲವು ಅನುಕೂಲಗಳು ಮತ್ತು ಅನನುಕೂಲಗಳು ಇದ್ದವು. ಕೇವಲ ಕೆಲವು ಪ್ರಮಾಣಿತ Windows ಸಾಮರ್ಥ್ಯಗಳೊಂದಿಗೆ ಕೆಲಸ ಮುಗಿಸುತ್ತಿದ್ದರೂ, ಬಹಳ ಸ್ಪಷ್ಟ ಮತ್ತು ವಿಸ್ತೃತ ಫೈಲ್ ಸಿಸ್ಟಂ ಬರಹಗಳಿಗೆ ಅವಕಾಶ ನೀಡುತ್ತಿತ್ತು ಮತ್ತು ಏರದ್ದಾಗಿ ನಡೆಯುತ್ತಿತ್ತು—ಅತಿಯಾದ ಏರುವಿಕೆ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಒಪ್ಪಬೇಕಾಗುವ ಅಥವಾ ಸ್ಥಳೀಯ ಯಂತ್ರದಲ್ಲಿ ಆಡ್ಮಿನ್‌ಗಳಾಗಿರಬೇಕಾಗುವ ಅಗತ್ಯವನ್ನು ಬಳಕೆದಾರರಿಗೆ ಕಡಿಮೆ ಮಾಡುತ್ತಿತ್ತು—ಆದರೂ ಇದರಲ್ಲಿ ಕೆಲವು ಗಂಭೀರ ನ್ಯೂನತೆಗಳಿದ್ದವು, ಅವುಗಳಲ್ಲಿ ಕೆಲವು ಇದನ್ನು ನಮ್ಮ ಅಂತಿಮ ವಿನ್ಯಾಸವಾಗುವುದರಿಂದ ಅನರ್ಹಗೊಳಿಸಿದವು:

• ಸೆಟಪ್ ವೇಗ: ವರ್ಕ್‌ಸ್ಪೇಸ್ ACL ಗಳನ್ನು ಅನ್ವಯಿಸುವುದು, ವರ್ಕ್‌ಸ್ಪೇಸ್ ಡೈರೆಕ್ಟರಿಯ ಟೊಪೋಲಾಜಿ ಮೇಲೆ ಅವಲಂಬಿಸಿ ದುಬಾರಿಯಾಗಬಹುದು.
• ಗುರುತು: ನಾವು ಡೆವಲಪರ್‌ನ ವ್ಯವಸ್ಥೆಯಲ್ಲೇ ನಿಜವಾದ ACL ಗಳನ್ನು ಅನ್ವಯಿಸಿದೆವು. ಆದರೆ ಇದು ವಿಶೇಷವಾಗಿ ಹಸ್ತಕ್ಷೇಪಕಾರಿ ಅಲ್ಲ, ಏಕೆಂದರೆ ಅನ್ವಯಿಸಲಾದ ಎಲ್ಲಾ ACL ಗಳು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಮಾತ್ರ ಬಳಸುವ, ವಿಶೇಷವಾಗಿ ರಚಿಸಿದ ಸಿಂಥೆಟಿಕ್ SID ಗೆ ಸಂಬಂಧಿಸುತ್ತವೆ.
• ಬದಲಾಯಿಸಲು ಕಷ್ಟವಾದ ಸಿಮೆಂಟಿಕ್ಸ್: ಫೈಲ್-ಆಧಾರಿತ ನಿರ್ಬಂಧಗಳಿಗಾಗಿ ACLs ಮೇಲೆ ಅವಲಂಬನೆಯಿರುವುದರಿಂದ, ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸಿಮೆಂಟಿಕ್ಸ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ವೆಚ್ಚಬರಿತ ಮತ್ತು ಸಂಕೀರ್ಣವಾಗುತ್ತದೆ. ಆದರೆ macOS ನಲ್ಲಿ, ನಾವು .sbpl ಅನ್ನು ಹೇಗೆ ರಚಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ಡೈನಾಮಿಕ್ ಆಗಿ ಬದಲಾಯಿಸಬಹುದು Seatbelt ಅನ್ನು ಸಂರಚಿಸಲು ಬಳಸುವ ಫೈಲ್, Windows sandbox ಗೆ ACLಗಳನ್ನು ಸರಿಹೊಂದಿಸಲು ನಿಧಾನವಾದ ಮತ್ತು ತೀವ್ರವಾದ ಕಾರ್ಯಾಚರಣೆಯ ಅಗತ್ಯವಿರಬಹುದು.
• ನೆಟ್‌ವರ್ಕ್ ರಕ್ಷಣೆ ದುರ್ಬಲವಾಗಿದೆ. ಮೊದಲೇ ಹೇಳಿದಂತೆ, ಅದು “ಸಲಹಾತ್ಮಕ” ಮಾತ್ರ, ತಮ್ಮದೇ networking stack ಜಾರಿಗೊಳಿಸಿದ ಕೆಲವು ಪ್ರೋಗ್ರಾಂಗಳು ಖಂಡಿತ ಅದನ್ನು ಮೀರಿ ಹೋಗುತ್ತವೆ ಮತ್ತು ವಿರೋಧಾತ್ಮಕ ಕೋಡ್ ಎದುರಿಸಲು ಅದನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಿಲ್ಲ.

ಮೊದಲ ಮೂರು ಸಮಸ್ಯೆಗಳು ಏಜೆಂಟಿಕ್ ಪ್ಲೋಗಳಿಗೆ ಸಾಕಷ್ಟು ಲವಚಿಕವಾಗಿರುವ ಕಸ್ಟಮ್ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನುಷ್ಠಾನಕ್ಕೆ ಸ್ವಭಾವತಃ ಸೇರಿವೆ. ಆದರೆ ನೆಟ್‌ವರ್ಕ್ ನಿಯಂತ್ರಣದ ಕಥೆ ವಿಭಿನ್ನವಾಗಿತ್ತು.

ದುರುದ್ದೇಶಿತ ಏಜೆಂಟ್ ಪರಿಸರ ಆಧಾರಿತ ನೆಟ್‌ವರ್ಕ್ ನಿಯಂತ್ರಣವನ್ನು ಸುಲಭವಾಗಿ ತಪ್ಪಿಸಿಕೊಳ್ಳುವುದರ ಜೊತೆಗೆ, ಹಲವು ಸದುದ್ದೇಶದ ಕೋಡ್/ಬೈನರಿಗಳೂ ವಾತಾವರಣ ಪ್ರಾಕ್ಸಿ ವೇರಿಯೆಬಲ್ ಗಳನ್ನು ಗೌರವಿಸದಿದ್ದರೆ ಅಥವಾ ತಮ್ಮದೇ ಸಾಕೆಟ್ ಆಧಾರಿತ ನೆಟ್‌ವರ್ಕ್ ಕೋಡ್ ಜಾರಿಗೊಳಿಸಿದ್ದರೆ ಅದನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಈ ಅಂಶವೇ ಉತ್ತಮ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಮೋಡ್‌ಗೆ ಹೂಡಿಕೆ ಮಾಡಲು ಸಾಕಷ್ಟಿದೆ ಎಂದು ನಮಗೆ ಅನಿಸಿತು.

ಉತ್ತಮ ನೆಟ್‌ವರ್ಕ್ ನಿಯಂತ್ರಣ ಪಡೆಯಲು, ನಾವು Windows Firewall ಬಳಸಲು ಬಯಸಿದೆವು. ಇದು ಬಳಕೆದಾರರು ಅಥವಾ ಪ್ರೋಗ್ರಾಂಗಳಿಗೆ ಹೊರಹೋಗುವ ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತಡೆಯಲು ಅವಕಾಶ ಮಾಡುತ್ತದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಕೆಲವು ಕಾರಣಗಳಿಂದ Codex harness ಪ್ರಾರಂಭಿಸುವ ಕಮಾಂಡ್‌ಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುವ ಕಾರ್ಯನಿರ್ವಹಣಾ ಫೈರ್ ವಾಲ್ ನಿಯಮವನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ರಚಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ:

• ನಿರ್ಬಂಧಿತ ಟೋಕನ್‌ನ ಪ್ರಿನ್ಸಿಪಲ್ ಅಲ್ಲದ ಗುರುತಿಗೆ ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು ಹೊಂದಿಸಲು Windows ಅನುಮತಿಸುವುದಿಲ್ಲ. ಇದರರ್ಥ, “ತನ್ನ ನಿರ್ಬಂಧಿತ SID ಪಟ್ಟಿಯಲ್ಲಿ ನಮ್ಮ ಸಿಂಥೆಟಿಕ್ SID ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಯಾವುದೇ ಟೋಕನ್" ಗೆ ಫೈರ್ ವಾಲ್ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.
• ನಾವು ನಿರ್ದಿಷ್ಟ ಬೈನರಿಗೆ ಹೊಂದುವ ಫೈರ್ ವಾಲ್ ನಿಯಮವನ್ನು ಸೃಷ್ಟಿಸಬಹುದಾದರೂ, ಅದು codex.exe ಗೇ ಮಾತ್ರ ನೆಟ್‌ವರ್ಕಿಂಗ್ ನಿಯಂತ್ರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಇದು ಬಳಕೆದಾರರ ಪರವಾಗಿ ಏಜೆಂಟ್ ಪ್ರಾರಂಭಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ Git ಅಥವಾ Python ಪ್ರಕ್ರಿಯೆಗಳು.
• ಇತರೆ ಫೈರ್‌ವಾಲ್ ಹೊಂದಾಣಿಕೆ ಆಯಾಮಗಳೂ ತಪ್ಪಾದ ರಚನೆಯಲ್ಲಿ ಇದ್ದವು. ಬಳಕೆದಾರ-ವ್ಯಾಪ್ತಿಯ ನಿಯಮಗಳು ಎಲಿವೇಟ್ ಮಾಡದ ವಿನ್ಯಾಸದಲ್ಲಿ ಕೇವಲ ನಿರ್ಬಂಧಿತ ಚೈಲ್ಡ್‌ಗೆ ಮಾತ್ರವಲ್ಲ, ನೈಜ Windows ಬಳಕೆದಾರನಿಗೂ ಇನ್ನೂ ಹೊಂದಿಕೆಯಾಗುತ್ತಿದ್ದವು. ಪ್ರೋಗ್ರಾಂ-ಪಾತ್ ನಿಯಮಗಳು ಅತಿಯಾಗಿ ಸ್ಥೂಲವಾಗಿದ್ದವು: ಅವು ಸಾಮಾನ್ಯವಾಗಿ codex.exe ಅಥವಾ python.exe ಅನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದಾಗಿದ್ದರೂ, python.exe ನ ಈ ನಿರ್ದಿಷ್ಟ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಮಾಡಿದ ಆಹ್ವಾನವನ್ನು ನಿರ್ಬಂಧಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತಿರಲಿಲ್ಲ. ಪೋರ್ಟ್- ಅಥವಾ ವಿಳಾಸ-ಆಧಾರಿತ ನಿಯಮಗಳೂ ಕೂಡ ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಾದ ನೀತಿಯಾಗಿದ್ದವು. ಉದಾಹರಣೆಗೆ, ನಾವು ಪೋರ್ಟ್ 443 ಅನ್ನು ನಿರ್ಬಂಧಿಸಲು ಬಯಸಲಿಲ್ಲ; ಈ ನಿರ್ದಿಷ್ಟ ನಿರ್ಬಂಧಿತ ಪ್ರಕ್ರಿಯೆ ವೃಕ್ಷದಿಂದ ಯಾವುದೇ ಅನಿಯಂತ್ರಿತ ಹೊರಮುಖ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಲು ಬಯಸಿದ್ದೆವು.

ನಮ್ಮ sandboxed ಕಮಾಂಡ್‌ಗಳಿಗೆ ಮಾತ್ರ ಫೈರ್ ವಾಲ್ ನಿಯಮ ಅನ್ವಯಿಸಲು, ಅವನ್ನು “ನಿಜವಾದ” ಬಳಕೆದಾರರಂತೆ ಅಲ್ಲ, ಪ್ರತ್ಯೇಕ ತತ್ತ್ವವಾಗಿ ಚಲಾಯಿಸಬೇಕಾಗಿತ್ತು. ಈ ವಿಧಾನವು ನಮ್ಮನ್ನು ಹೊಸ ದಾರಿಗೆ ಕರೆದೊಯ್ದಿತು—ಅಂದರೆ, “ಏರಿಕೆ ಬೇಡ” ಎಂಬ ನಿರ್ಬಂಧವನ್ನು ನಾವು ಸಡಿಲಗೊಳಿಸಿದ ದಾರಿ.

ನಮ್ಮ ಪ್ರಸ್ತುತ ಅನುಷ್ಠಾನವಾಗಿರುವ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನ ಮುಂದಿನ ಆವೃತ್ತಿಗೆ, ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ ಉನ್ನತ ನಿರ್ವಾಹಕ ಅನುಮತಿಗಳು ಅಗತ್ಯವಿರುತ್ತವೆ. ಆದ್ದರಿಂದ ನಾನು ಅದನ್ನು “ಎಲಿವೇಟೆಡ್ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್” ಎಂದು ಕರೆಯುತ್ತೇನೆ. ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ Codex ಒಂದು ಕಮಾಂಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಸೀಮೆಯಲ್ಲಿ, ಹೆಚ್ಚಿನ ಹಕ್ಕುಗಳಿರುವ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಹೆಚ್ಚಿನ ಹಕ್ಕುಗಳಿಲ್ಲದ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಂತೆಯೇ ಕಾಣುತ್ತದೆ. ಇದು ಇನ್ನೂ ನಿರ್ಬಂಧಿತ ಟೋಕನ್ ಅಡಿಯಲ್ಲಿ ಚೈಲ್ಡ್ ಪ್ರೊಸೆಸ್‌ಗಳನ್ನು ರನ್ ಮಾಡುತ್ತದೆ—ಅದೇ ರೀತಿ [ಎಲ್ಲರೂ, ಲಾಗಾನ್,ಸಿಂಥೆಟಿಕ್] ಎಂಬ ಅದೇ ನಿರ್ಬಂಧಿತ SID ಪಟ್ಟಿಯೊಂದಿಗೆ ಇರುವ write_restrictedಟೋಕನ್—ಆದಾಗ್ಯೂ, ಈ ಟೋಕನ್‌ನ ಪ್ರಿನ್ಸಿಪಲ್ ಇನ್ನು ಮುಂದೆ ನಿಜವಾದ Windows ಬಳಕೆದಾರನಲ್ಲ, ಬದಲಾಗಿ Codex ತಾನೇ ರಚಿಸಿದ ಎರಡು ಸ್ಥಳೀಯ ಬಳಕೆದಾರರಲ್ಲಿ ಒಬ್ಬನಾಗಿರುತ್ತದೆ:

• CodexSandboxOffline (ಫೈರ್ ವಾಲ್ ನಿಯಮಗಳ ಗುರಿಯಾಗಿರುವವನು)
• CodexSandboxOnline (ಫೈರ್ ವಾಲ್ ನಿಯಮಗಳ ಗುರಿಯಾಗದವನು)

ಕಾಣುವಷ್ಟರಲ್ಲಿ ಸಣ್ಣದಾಗಿ ತೋರುವ ಈ ವಿವರವು ವಾಸ್ತವವಾಗಿ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್, ಅದನ್ನು ಯಾರು ಬಳಸಬಹುದು ಮತ್ತು ಅದರ ಸೆಟಪ್ ಹಾಗೂ ರನ್‌ಟೈಮ್ ಅನುಷ್ಠಾನದ ಸಂಕೀರ್ಣತೆ ಮೇಲೆ ದೊಡ್ಡ ಪರಿಣಾಮಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ದೃಶ್ಯಾತ್ಮಕವಾಗಿ ಇದು ಏರದ ಪ್ರೋಟೋಟೈಪ್ ಗೆ ಹೋಲುತ್ತದೆ, ಆದರೆ ಫೈರ್ ವಾಲ್ ನಿಯಮಗಳು ಮತ್ತು ಕಮಾಂಡ್‌ಗಳನ್ನು ನಿಜವಾಗಿ ಚಲಾಯಿಸುವ ವಿಶೇಷ Windows ಬಳಕೆದಾರರನ್ನು ಪರಿಚಯಿಸಲಾಗಿದೆ. (ಆದಾಗ್ಯೂ, ಈ ಹೊಸ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಸೇರಿಸಿದ ಪರಿಣಾಮ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಕಮಾಂಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸಿ ರಕ್ಷಿಸಲು ಆರಂಭಿಸುವ ಮೊದಲು ಇನ್ನಷ್ಟು ಸೆಟಪ್ ಕೆಲಸ ಬೇಕಾಗುತ್ತದೆ.)

ಏರದ sandbox ವಿನ್ಯಾಸದಲ್ಲಿ ಸರಳ ಸೆಟಪ್ ಹಂತವಿತ್ತು, ಆದರೆ ಅದು ತುಸು ಚಿಕ್ಕದಾಗಿತ್ತು:

• ಅಗತ್ಯವಿದ್ದರೆ ಸಿಂಥೆಟಿಕ್ SID ರಚಿಸಿ
• sandbox-write ಸಿಂಥೆಟಿಕ್ SID ಗೆ ACL ಗಳನ್ನು ಅನ್ವಯಿಸಿ

ಆದರೆ ಏರಿದ sandbox ಗೆ ಇನ್ನೂ ಹೆಚ್ಚು ಕೆಲಸಗಳಿವೆ.

• ಇನ್ನೂ ರಚಿಸದಿದ್ದರೆ ಸಿಂಥೆಟಿಕ್ SID ರಚಿಸಿ
• ಇನ್ನೂ ರಚಿಸದಿದ್ದರೆ ಆನ್ ಲೈನ್ ಮತ್ತು ಆಫ್ ಲೈನ್ sandbox ಬಳಕೆದಾರರನ್ನು ರಚಿಸಿ
• ಹೊಸದಾಗಿ ರಚಿಸಲಾದ ಬಳಕೆದಾರರ ಋಜುವಾತುಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಸಂಗ್ರಹಿಸಿ ಮತ್ತು sandbox ಬಳಕೆದಾರರು ನಿಜವಾಗಿ ಓದಲಾರದ ಸ್ಥಳದಲ್ಲಿ Windows Data Protection API (DPAPI) ಬಳಸಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿ
• CodexSandboxOffline ಬಳಕೆದಾರನಿಗೆ ಎಲ್ಲಾ ಹೊರಹೋಗುವ ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶವನ್ನು ತಡೆಯುವ firewall ನಿಯಮಗಳನ್ನು ರಚಿಸಿ ಅಥವಾ ಅವು ಈಗಾಗಲೇ ಇದ್ದರೆ ಅವು ಸರಿಯಾಗಿವೆ ಎಂದು ಮಾನ್ಯಗೊಳಿಸಿ

ಸೆಟಪ್ ಹಂತದಲ್ಲಿ ಇನ್ನೊಂದು ಹೆಚ್ಚುವರಿ ತೊಡಕು ಇದೆ. Codex‌ನ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್, ನಿಜವಾದ Windows ಬಳಕೆದಾರನಿಗೆ ಸಮಾನವಾದ ಓದುವ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. ನಿರ್ಬಂಧಿತ ಟೋಕನ್‌ನ ಪ್ರಿನ್ಸಿಪಲ್ SID Windows ಬಳಕೆದಾರನಾಗಿದ್ದ ಉನ್ನತೀಕರಿಸದ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಇದನ್ನು ಸಾಧಿಸಲಾಯಿತು. ಆದರೆ, ಪ್ರಿನ್ಸಿಪಲ್ ಹೊಸ CodexSandbox ಬಳಕೆದಾರರಾದಾಗ ಅದು ಸ್ವಯಂ ಲಭ್ಯವಾಗುವುದಿಲ್ಲ. Windows ನಲ್ಲಿನ ಅನೇಕ ಸಂಬಂಧಿತ ಡೈರೆಕ್ಟರಿಗಳು “ಅಧಿಕೃತ ಬಳಕೆದಾರರು” ಗೆ ಓದಲು/ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅನುಮತಿಗಳನ್ನು ನೀಡುತ್ತವೆ. ಒಂದು ಗಮನಾರ್ಹ ಉದಾಹರಣೆಯೆಂದರೆ ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ ಡೈರೆಕ್ಟರಿ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, Windows ಬಳಕೆದಾರರು ಇತರ Windows ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಓದಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸರಳ ಫೈಲ್ ಓದುವಿಕೆಗಳೂ ಸಹ ವಿಫಲವಾಗುತ್ತವೆ.

ಇದನ್ನು ಸರಿಪಡಿಸಲು, ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸೆಟಪ್ ಪ್ರಕ್ರಿಯೆಗೆ ನಾವು ಇನ್ನೊಂದು ಪದರವನ್ನು ಸೇರಿಸಿದೆವು—ಅಂದರೆ, ಇಂತಹ ACL ಗಳು ಈಗಾಗಲೇ ಇಲ್ಲದಿರಬಹುದಾದ ಸ್ಥಳಗಳಲ್ಲಿ sandbox ಬಳಕೆದಾರರಿಗೆ read ACL ಗಳನ್ನು ನೀಡುವ ಪದರ. ಉದಾಹರಣೆಗೆ, ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲಾಗುವ ಕೆಲವು Windows ಡೈರೆಕ್ಟರಿಗಳಿಗೆ:

• C:\Users\<real-user>
• C:\Windows\
• C:\Program Files\
• C:\Program Files (x86)\
• C:\ProgramData\

ಈ ಡೈರೆಕ್ಟರಿಗಳ ಪಟ್ಟಿಯು ಅತ್ಯುತ್ತಮ ಪರಿಶ್ರಮ ಆಧಾರಿತವಾಗಿರುವುದರಿಂದ ಮತ್ತು ಪ್ರತಿಯೊಂದರಲ್ಲೂ ACL ಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದು ಸಾಕಷ್ಟು ದುಬಾರಿಯಾಗುವುದರಿಂದ, ಬಳಕೆದಾರರಿಗೆ ತಡೆಯಾಗಿ ಇರುವ sandbox setup ಹಂತವು ಅವು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಾಯಬೇಕಾಗದಂತೆ, ಈ ತರ್ಕವನ್ನು ನಾವು ಅಸಿಂಕ್ರೋನಸ್ ಆಗಿ ಚಲಾಯಿಸುತ್ತೇವೆ.

ಅಗತ್ಯವಿರುವಾಗ ಮಾತ್ರ UAC ಗಡಿಯನ್ನು ದಾಟಲು ಸಾಧ್ಯವಾಗುವಂತೆ, ನಾವು ಸೆಟಪ್ ಲಾಜಿಕ್ ಅನ್ನು ಭಾಗಶಃ ಅದರದೇ ಆದ ಬೈನರಿಯಲ್ಲಿ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟ್ ಮಾಡಿದ್ದೇವೆ. ಆದರೆ ಆಳವಾದ ಕಾರಣವು ಆರ್ಕಿಟೆಕ್ಚರ್-ಸಂಬಂಧಿತವಾಗಿತ್ತು: ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸೆಟಪ್‌ಗೆ codex.exe ಗಿಂತ ಮೂಲಭೂತವಾಗಿ ವಿಭಿನ್ನವಾದ ಕೆಲಸವಿದೆ. sandbox ಹೊಂದಿಸುವಿಕೆ ತರ್ಕವನ್ನು ವಿಶೇಷ ಬೈನರಿಯಲ್ಲಿಡುವುದರಿಂದ codex.exe ಸಾಮಾನ್ಯ, ಏರದ ಹಾರ್ನೆಸ್ ಆಗಿ ಉಳಿಯಲು ಸಾಧ್ಯವಾಯಿತು; Windows ಮಾತ್ರದ ಸೆಟಪ್ ವ್ಯವಸ್ಥೆಗಳು ಇತರ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ codex.exe ಅನ್ನು ಅನಾವಶ್ಯಕವಾಗಿ ಭಾರೀಗೊಳಿಸುವುದನ್ನು ತಡೆಯಿತು; ದೀರ್ಘಕಾಲದ ಸೆಟಪ್ ಕೆಲಸವನ್ನು ಮುಖ್ಯ ಪ್ರಕ್ರಿಯೆಯ ಆಯುಷ್ಯದಿಂದ ಬೇರ್ಪಡಿಸಿತು; ಮತ್ತು sandbox ಗೆ ಬೇಕಾದ ವಿವಿಧ ಹೊಂದಿಕೆ ಮಾರ್ಗಗಳನ್ನು ನಿಭಾಯಿಸಲು ನಮಗೆ ಒಂದು ಏಕೈಕ ಸ್ಥಳ ಒದಗಿಸಿತು.

Windows ಬಳಕೆದಾರ ಮತ್ತು ಟೋಕನ್ ಲಾಗಿನ್ ಗಡಿಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ರೀತಿಯ ಕಾರಣದಿಂದ, ನಿರ್ಬಂಧಿತ ಟೋಕನ್ ರಚಿಸಿ ಅದರಡಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ವಿಧಾನವನ್ನು ಏರದ sandbox ನಲ್ಲಿ ಮಾಡಿದಂತೆ ಮುಂದುವರಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ನಿಜವಾಗಿ ಬೇರೆ Windows ಬಳಕೆದಾರರಾಗಿ ಕಮಾಂಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು, ಮೊದಲಿಗೆ ನಾವು ಈ ಕೆಳಗಿನ ಪ್ರವಾಹವನ್ನು ಊಹಿಸಿದೆವು:

• codex.exe ನಿಜವಾದ Windows ಬಳಕೆದಾರರಾಗಿ ರನ್ ಆಗುತ್ತದೆ. ನಂತರ, ಅನುಕ್ರಮವಾಗಿ, Codex:
  • ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಬಳಕೆದಾರರಿಗಾಗಿ LogonUserW(...) ಅನ್ನು ಕರೆಮಾಡುತ್ತದೆ.
  • ಆ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್-ಬಳಕೆದಾರ ಟೋಕನ್ ಮೇಲೆ CreateRestrictedToken(...) ಅನ್ನು ಕರೆ ಮಾಡುತ್ತದೆ.
  • ಆ ನಿರ್ಬಂಧಿತ sandbox-user ಟೋಕನ್ ಅನ್ನು ಬಳಸಿ, ಅಂತಿಮ ಚೈಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು CreateProcessAsUserW(...) ಅನ್ನು ಕರೆ ಮಾಡುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ, CreateProcessAsUserW(...) ನಲ್ಲಿ ವಿಶೇಷಾಧಿಕಾರದ ಅಡೆತಡೆ ಎದುರಾದ ಕಾರಣ ಆ ಬಯಸಿದ ಹರಿವು ಕಾರ್ಯನಿರ್ವಹಿಸಲಿಲ್ಲ. ಇದರರ್ಥ codex.exe ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಬಳಕೆದಾರರಿಗಾಗಿ ನಿರ್ಬಂಧಿತ ಟೋಕನ್ ಅನ್ನು ರಚಿಸಬಹುದಾಗಿತ್ತು, ಆದರೆ ಮೇರೆಯ ನಿಜವಾದ ಬಳಕೆದಾರರ ಬದಿಯಿಂದ ಆ ಟೋಕನ್‌ನೊಂದಿಗೆ ಚೈಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಪ್ರಾರಂಭಿಸಲು ಅದಕ್ಕೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಬಳಕೆದಾರನಾಗಿ ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿದ್ದ ಒಂದು ಪ್ರಕ್ರಿಯೆ ನಮಗೆ ಬೇಕಿತ್ತು—ಇದರಿಂದ ನಿರ್ಬಂಧಿಸುವ ಹಂತ ಮತ್ತು ಅಂತಿಮ ಸ್ಪಾನ್, ನಿಜವಾದ ಬಳಕೆದಾರನ ಬದಿಯ ಬದಲು ಗಡಿಯ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಬಳಕೆದಾರನ ಬದಿಯಲ್ಲಿ ನಡೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತಿತ್ತು.

ಆ ಅವಶ್ಯಕತೆಯು codex-command-runner.exe ಗೆ ಕಾರಣವಾಯಿತು, ಇದು ಹೊಸ ಬೈನರಿಯಾಗಿದ್ದು, ಇದರ ಏಕೈಕ ಕೆಲಸವೆಂದರೆ ನಿರ್ಬಂಧಿತ ಟೋಕನ್ ಅನ್ನು ರಚಿಸಿ, ವಿನಂತಿಸಿದ ಕಮಾಂಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವುದು. ಸಂಪೂರ್ಣ ಪ್ರವಾಹವನ್ನೇ (ನೈಜ ಬಳಕೆದಾರ → sandbox ಬಳಕೆದಾರ → ನಿರ್ಬಂಧಿತ ಟೋಕನ್ → ಚೈಲ್ಡ್ ಪ್ರಕ್ರಿಯೆ) codex.exe ತಾನೇ ಮಾಡುವಂತೆ ಕೇಳುವ ಬದಲು, ನಾವು ಅದನ್ನು ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸಿದೆವು:

ಭಾಗ 1

• codex.exe, ಇನ್ನೂ ನಿರ್ಬಂಧಿತ ಟೋಕನ್ ಬಳಸದೆ, sandbox ಬಳಕೆದಾರರಾಗಿ codex-command-runner.exe ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು CreateProcessWithLogonW(...) ಅನ್ನು ಕರೆಮಾಡುತ್ತದೆ.

ಭಾಗ 2

• ರನ್ನರ್ ಒಳಗೆ, OpenProcessToken(GetCurrentProcess(), ...) runner‌ನ ಸ್ವಂತ ಟೋಕನ್ ಅನ್ನು ತೆರೆಯುತ್ತದೆ, ಅದು ಈಗಾಗಲೇ sandbox ಬಳಕೆದಾರನಿಗೆ ಸೇರಿದೆ.
• ರನ್ನರ್, sandbox ಲಾಗಾನ್ SID ಅನ್ನು ಹೊರತೆಗೆದುಕೊಳ್ಳಲು GetTokenInformation(...) ಅನ್ನು ಕರೆಮಾಡುತ್ತದೆ, ನಂತರ ಅಂತಿಮ ನಿರ್ಬಂಧಿತ ಟೋಕನ್ ಅನ್ನು ನಿರ್ಮಿಸಲು CreateRestrictedToken(...) ಅನ್ನು ಕರೆಮಾಡುತ್ತದೆ.
• ಇನ್ನೂ ರನ್ನರ್ ಒಳಗೇ, ಅದು ಆ ನಿರ್ಬಂಧಿತ ಟೋಕನ್ ಬಳಸಿ ನಿಜವಾದ ಚೈಲ್ಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು CreateProcessAsUserW(...) ಅನ್ನು ಕರೆಮಾಡುತ್ತದೆ.

ಆಲ್ಬರ್ಟ್ ಐನ್‌ಸ್ಟೈನ್ ಹೇಳಿದ್ದಾನೆ, “ಎಲ್ಲವನ್ನೂ ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ಮಾಡಬೇಕು, ಆದರೆ ಅದಕ್ಕಿಂತ ಸರಳವಾಗಿಸಬಾರದು.” ಆ ಮನೋಭಾವದಲ್ಲಿ, ನಮ್ಮ ವಿನ್ಯಾಸ ಪ್ರತಿಯೊಂದು ಸಮಸ್ಯೆಯನ್ನೂ ಸಮರ್ಪಕವಾಗಿ ಪರಿಹರಿಸಿತು. ಅಂತಿಮ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ ನಾವು ಈಗಾಗಲೇ ಒಳಗೊಂಡಿರುವ ನಾಲ್ಕು ಪದರಗಳಿವೆ:

• codex.exe ತಾನೇ
• ಎಲ್ಲ ಏರಿದ ಹೊಂದಿಕೆ ಸಂಬಂಧಿತ ಕೆಲಸ ನಿಭಾಯಿಸಲು codex-windows-sandbox-setup.exe
• ನಿರ್ಬಂಧಿತ ಟೋಕನ್ ಕಮಾಂಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು codex-command-runner.exe
• ಚೈಲ್ಡ್ ಪ್ರೊಸೆಸ್

ನಾನು ಮೊದಲಿಗೆ ಈ ಯೋಜನೆಯತ್ತ ಬಂದಾಗ, ಇದು ಅಂತಿಮವಾಗಿ ಎಲ್ಲಿಗೆ ತಲುಪಬಹುದು ಎಂಬುದರ ಬಗ್ಗೆ ಸ್ಪಷ್ಟ ಕಲ್ಪನೆ ಇರಲಿಲ್ಲ. ನನ್ನ ವಿಧಾನವೆಂದರೆ Codex ಮತ್ತು ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಯ ನಡುವಿನ ಗಡಿಯಲ್ಲೇ sandboxing ಸಾಮರ್ಥ್ಯವನ್ನು ಸಾಧನಗೊಳಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸುವುದು. ಈ ವಿಧಾನವು MacOs ಮತ್ತು Linux ನಲ್ಲಿ Codex ನ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಜಾರಿಗೊಳ್ಳುವ ರೀತಿಗೆ ಹತ್ತಿರವಾಗಿ ಹೊಂದುತ್ತದೆ.

Windows ಒದಗಿಸುವ ನಿರ್ದಿಷ್ಟ ಉಪಕರಣಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚು ಕಲಿತಂತೆ ಮತ್ತು ಭದ್ರತೆ ಹಾಗೂ ಬಳಕೆ ಸುಲಭತೆ ನಡುವಿನ ಡಜನ್‌ಗಟ್ಟಲೆ ನಿರ್ಧಾರಗಳ ಮೂಲಕ, ಈ ವ್ಯವಸ್ಥೆ ಇಂದಿನ ರೂಪಕ್ಕೆ ಬೆಳೆಯಿತು—ಅನೇಕ ಬೈನರಿಗಳು, ಕಸ್ಟಮ್ ಬಳಕೆದಾರರು, ಫೈರ್ ವಾಲ್ ನಿಯಮಗಳು, ಏರಿದ ಹೊಂದಿಕೆ ಹಂತ, ಅಸಿಂಕ್ರನಸ್ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಇನ್ನೂ ಬಹಳಷ್ಟು.

ಇದು ಅತ್ಯಂತ ಸರಳ ವ್ಯವಸ್ಥೆಯಲ್ಲ. ಆದರೆ ಪ್ರತಿಯೊಂದು ಸಂಕೀರ್ಣತೆಯ ತುಣುಕನ್ನೂ ಅವಶ್ಯಕತೆಯಿಂದಲೇ ಸೇರಿಸಲಾಯಿತು—ಸುರಕ್ಷಿತವಾಗಿಯೂ, ಸಾಧ್ಯವಾದಷ್ಟು ಬಳಕೆದಾರರಿಗೆ ತೊಂದರೆಯಾಗದಂತೆಯೂ ಇರುವ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ನಿರ್ಮಿಸಲು.

Windows ನಲ್ಲಿ Codex ಬಳಕೆದಾರರಿಗೆ ಉತ್ತಮ ಅನುಭವ ನೀಡಲು ಕೆಲಸ ಮಾಡುವಾಗ, ಉಪಯುಕ್ತತೆಯನ್ನು ಬಲಿಕೊಡದ ಸುರಕ್ಷಿತವಾದ ಯಾವುದನ್ನಾದರೂ ನಿರ್ಮಿಸುವುದೇ ನಮ್ಮ ಗುರಿಯಾಗಿತ್ತು—ನಿರಂತರ ನಿಮ್ಮ ಗಮನವಿಲ್ಲದೇ ಏಜೆಂಟ್‌ಗಳು ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದೇ Codex ಬಳಸುವ ಮುಖ್ಯ ಉದ್ದೇಶ.

ಈ ಯೋಜನೆಯಿಂದ ಪಡೆದ ದೊಡ್ಡ ಪಾಠಗಳಲ್ಲಿ ಒಂದು ಎಂದರೆ, Windows ನಮ್ಮ ಕೈಗೆ “ಸುರಕ್ಷಿತ ಸ್ವಾಯತ್ತ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್” ಗೆ ಸರಿಯಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವ ಒಂದೇ ಮೂಲಾಂಶವನ್ನು ನೀಡಲಿಲ್ಲ. ನಾವು ಹಲವಾರು ಉಪಕರಣಗಳು ಮತ್ತು ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಸೇರಿಸಿ ಸಮಗ್ರವಾದದ್ದನ್ನು ನಿರ್ಮಿಸಿದೆವು. ಕೆಲವು ಆರಂಭಿಕ ಕಲ್ಪನೆಗಳು ಕೊನೆಯವರೆಗೂ ಸಾಗಲಿಲ್ಲ. ಅಂತಿಮ ವಿನ್ಯಾಸವು ಹಿಂದಿನ ಪ್ರೋಟೋಟೈಪ್‌ಗಳ ಮಿಶ್ರಣವಾಗಿದ್ದು, ಪ್ರತಿಯೊಂದು ಸಮಸ್ಯೆಯ ಒಂದು ಭಾಗವನ್ನು ಪರಿಹರಿಸಿತು.

ಮತ್ತೊಂದು ಪಾಠವೆಂದರೆ, ಕೋಡಿಂಗ್ ಏಜೆಂಟ್‌ಗೆ ಬೇಕಾದ ಭದ್ರತೆ, ಸಾಂಪ್ರದಾಯಿಕ ಅನ್ವಯ ಭದ್ರತೆಯಿಂದ ಸಂಪೂರ್ಣ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. Codex ನಿಜವಾದ ಡೆವಲಪರ್ ವರ್ಕ್‌ಫ್ಲೋಗಳಿಗೆ ಕೆಲಸ ಮಾಡಲೇಬೇಕು. ಎಂಜಿನಿಯರಿಂಗ್ ಕೆಲಸವೆಂದರೆ ಏಜೆಂಟಿಕ್ ವರ್ಕ್‌ಲೋಡ್‌ಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳುವಿಕೆ ಮತ್ತು ನಿಜವಾದ ಜಾರಿಗೆ ನಡುವೆ ಸಮತೋಲನ ಸಾಧಿಸುವುದು. ಆ ಒತ್ತಡವೇ ಅಂತಿಮ ವಿನ್ಯಾಸದ ವಿನಿಮಯಗಳನ್ನು ರೂಪಿಸಿತು.

Codex ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಹೇಗಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಕುತೂಹಲವೇ? ಇದನ್ನು ಪ್ರಯತ್ನಿಸಿ⁠.