Windows 'ਤੇ Codex ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੈਂਡਬਾਕਸ ਬਣਾਉਣਾ

ਜਦੋਂ ਮੈਂ ਸਤੰਬਰ 2025 ਵਿੱਚ Codex ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਇਆ, ਤਾਂ Windows ਲਈ Codex ਕੋਲ ਕੋਈ ਸੈਂਡਬਾਕਸ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨਹੀਂ ਸੀ, ਜਿਸਦਾ ਮਤਲਬ ਸੀ ਕਿ OpenAI ਦੇ ਕੋਡਿੰਗ ਏਜੰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ Windows ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਦੋ ਘੱਟ ਮਿਆਰੀ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਚੋਣ ਕਰਨ ਲਈ ਮਜਬੂਰ ਹੋਣਾ ਪੈਂਦਾ ਸੀ:

1. ਕੋਡਿੰਗ ਏਜੰਟ ਦੁਆਰਾ ਚਲਾਏ ਜਾਣ ਵਾਲੇ ਲਗਭਗ ਹਰ ਕਮਾਂਡ (ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਿਰਫ ਪੜ੍ਹਨ ਵਾਲੀਆਂ ਵੀ) ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣਾ, ਜੋ ਕਿ ਅਕੁਸ਼ਲ ਅਤੇ ਪਰੇਸ਼ਾਨੀ ਭਰਿਆ ਹੈ। Codex ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਇੱਕ ਵੱਡਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਸਾਰਾ ਮੁਸ਼ਕਲ ਅਤੇ ਅਕਾਊ ਕੰਮ ਖੁਦ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ।
2. 'ਫੁੱਲ ਐਕਸੈਸ' ਮੋਡ ਨੂੰ ਚਾਲੂ ਕਰਨਾ: Codex ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਮਨਜ਼ੂਰੀ ਜਾਂ ਪਾਬੰਦੀ ਦੇ ਸਾਰੀਆਂ ਕਮਾਂਡਾਂ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਾ, ਜੋ ਨਿਗਰਾਨੀ ਦੀ ਕੀਮਤ 'ਤੇ ਕੰਮ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

Codex⁠, ਸਾਡਾ ਕੋਡਿੰਗ ਏਜੰਟ, ਡਿਵੈਲਪਰ ਲੈਪਟਾਪਾਂ 'ਤੇ ਚੱਲਦਾ ਹੈ—ਚਾਹੇ ਉਹ CLI, IDE ਐਕਸਟੈਂਸ਼ਨ, ਜਾਂ ਡੈਸਕਟੌਪ ਐਪ ਰਾਹੀਂ ਹੋਵੇ। ਇਹ ਕੀਬੋਰਡ 'ਤੇ ਬੈਠੇ ਇਨਸਾਨ ਅਤੇ ਕਲਾਊਡ ਵਿੱਚ ਚੱਲ ਰਹੇ ਮਾਡਲ ਵਿਚਕਾਰ ਗੱਲਬਾਤ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ।

Codex ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਇੱਕ ਅਸਲ ਉਪਭੋਗਤਾ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਨਾਲ ਚੱਲਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਉਹ ਸਭ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ ਅਤੇ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਖਤਰਨਾਕ ਵੀ। ਕੋਡਿੰਗ ਮਾਡਲ ਸਿਸਟਮ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕਮਾਂਡਾਂ ਚਲਾਉਣ ਲਈ ਕਹਿ ਸਕਦਾ ਹੈ—ਟੈਸਟ ਚਲਾਉਣ ਤੋਂ ਲੈ ਕੇ ਫਾਈਲ ਪੜ੍ਹਨ ਜਾਂ ਐਡਿਟ ਕਰਨ ਅਤੇ ਗਿੱਟ (Git) ਬ੍ਰਾਂਚ ਬਣਾਉਣ ਤੱਕ—ਇਸ ਲਈ Codex ਦਾ ਡਿਫੌਲਟ ਮੋਡ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਵਿਚਕਾਰ ਸਹੀ ਸੰਤੁਲਨ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਡਿਫੌਲਟ ਮੋਡ Codex ਨੂੰ ਲਗਭਗ ਕਿਤੇ ਵੀ ਫਾਈਲਾਂ ਪੜ੍ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਵਰਕਸਪੇਸ (ਯਾਨੀ ਉਹ ਡਾਇਰੈਕਟਰੀ ਜਿੱਥੇ ਤੁਸੀਂ Codex ਚਲਾ ਰਹੇ ਹੋ) ਦੇ ਅੰਦਰ ਫਾਈਲਾਂ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਖੁਦ ਨਾ ਚਾਹੋ, ਇੰਟਰਨੈੱਟ ਤੱਕ ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ ਹੁੰਦੀ। ਫਾਈਲਾਂ ਲਿਖਣ ਅਤੇ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੁਰੱਖਿਅਤ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਆਟੋਮੈਟਿਕਲੀ ਸੀਮਤ ਕਰਨ ਲਈ, Codex ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਸੈਂਡਬਾਕਸ ਵਾਤਾਵਰਣ ਦੀ ਲੋੜ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਇਹਨਾਂ ਪਾਬੰਦੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕੇ।

ਇੱਕ ਸੈਂਡਬਾਕਸ ਇੱਕ ਸੀਮਤ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਾਤਾਵਰਣ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਡਿਵੈਲਪਰ Codex ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਦੇ ਕੰਪਿਊਟਰ ਦਾ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਘੱਟ ਇਜਾਜ਼ਤਾਂ ਨਾਲ ਇੱਕ ਕਮਾਂਡ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਪਾਬੰਦੀਆਂ ਪੂਰੇ ਪ੍ਰੋਸੈਸ ਟ੍ਰੀ ਵਿੱਚ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ। ਹਰ Codex ਕਮਾਂਡ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸੈਂਡਬਾਕਸਡ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਹਰ ਉਪ-ਪ੍ਰਕਿਰਿਆ ਉਸੇ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਹਿੰਦੀ ਹੈ।

Codex ਨੂੰ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੈਂਡਬਾਕਸ ਲਾਗੂ ਕਰਨ ਲਈ ਕੰਪਿਊਟਰ ਦੇ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੀਆਂ ਆਈਸੋਲੇਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਕੁਝ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਜਿਹੇ ਟੂਲ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜੋ ਇਹ ਕੰਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦੇ ਹਨ (ਜਿਵੇਂ ਕਿ MacOS 'ਤੇ Seatbelt, Linux 'ਤੇ seccomp ਜਾਂ bubblewrap); ਹਾਲਾਂਕਿ, Windows ਵਰਤਮਾਨ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ (out of the box) ਇਸ ਕਿਸਮ ਦੀ ਸਮੱਰਥਾ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ।

Codex ਨੂੰ Windows 'ਤੇ ਵੀ ਉਨਾ ਹੀ ਸੁਰੱਖਿਅਤ ਅਤੇ ਵਰਤਣ ਵਿੱਚ ਸੁਖਦ ਬਣਾਉਣ ਲਈ, ਸਾਨੂੰ ਆਪਣਾ ਸੈਂਡਬਾਕਸ ਖੁਦ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਸੀ।

Windows ਆਈਸੋਲੇਸ਼ਨ ਲਈ ਕੁਝ ਟੂਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਾਡੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ ਸੀ, ਅਸੀਂ ਕਈ ਸੰਭਾਵੀ ਹੱਲਾਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ—ਮੁੱਖ ਤੌਰ 'ਤੇ AppContainer, Windows Sandbox, ਅਤੇ Mandatory Integrity Control ਲੇਬਲਿੰਗ।

AppContainer

• ਕੀ ਹੈ: AppContainer Windows ਦਾ ਮੂਲ ਸੈਂਡਬਾਕਸ ਹੈ, ਇੱਕ ਸਮਰੱਥਾ-ਅਧਾਰਿਤ ਆਈਸੋਲੇਸ਼ਨ ਮਾਡਲ ਜੋ ਉਹਨਾਂ ਐਪਸ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਜਾਣਦੀਆਂ ਹਨ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਸ ਚੀਜ਼ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੈ।
• ਕਿਉਂ: ਇਹ ਆਕਰਸ਼ਕ ਸੀ ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ ਸਧਾਰਨ ਪਾਬੰਦੀਆਂ ਦੀ ਬਜਾਏ ਇੱਕ ਅਸਲ OS ਸੀਮਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
• ਕਿਉਂ ਨਹੀਂ: Codex ਕੋਈ ਇੱਕ ਸੀਮਤ ਦਾਇਰੇ ਵਾਲੀ ਐਪ ਨਹੀਂ ਹੈ। ਇਹ ਡਿਵੈਲਪਰ ਦੇ ਖੁੱਲ੍ਹੇ ਕੰਮਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ: ਸ਼ੈੱਲ, ਗਿੱਟ, ਪਾਈਥਨ, ਪੈਕੇਜ ਮੈਨੇਜਰ, ਬਿਲਡ ਟੂਲ, ਅਤੇ ਹੋਰ ਜੋ ਵੀ ਬਾਈਨਰੀਆਂ ਏਜੰਟ ਨੂੰ ਚਾਹੀਦੀਆਂ ਹਨ। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਸ ਨੇ AppContainer ਨੂੰ ਇਸ ਸਮੱਸਿਆ ਲਈ ਗਲਤ ਸਾਬਤ ਕਰ ਦਿੱਤਾ। ਇਹ ਮਜ਼ਬੂਤ ਆਈਸੋਲੇਸ਼ਨ ਤਾਂ ਸੀ, ਪਰ ਇਹ "ਏਜੰਟ ਨੂੰ ਡਿਵੈਲਪਰ ਵਾਂਗ ਕੰਮ ਕਰਨ ਦੇਣ" ਵਰਗੇ ਵਿਆਪਕ ਕੰਮਾਂ ਲਈ ਬਹੁਤ ਤੰਗ ਸੀ।

Windows ਸੈਂਡਬਾਕਸ

• ਕੀ ਹੈ: Windows ਸੈਂਡਬਾਕਸ ਮਾਈਕਰੋਸਾਫਟ ਦੀ ਇੱਕ ਡਿਸਪੋਜ਼ੇਬਲ ਲਾਈਟਵੇਟ VM (ਵਰਚੁਅਲ ਮਸ਼ੀਨ) ਹੈ। ਤੁਹਾਨੂੰ ਇੱਕ ਮਜ਼ਬੂਤ ਆਈਸੋਲੇਸ਼ਨ ਸੀਮਾ ਦੇ ਨਾਲ ਇੱਕ ਨਵਾਂ Windows ਡੈਸਕਟੌਪ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਜੋ ਕੁਝ ਵੀ ਤੁਸੀਂ ਇਸਦੇ ਅੰਦਰ ਕਰਦੇ ਹੋ, ਸੈਸ਼ਨ ਖਤਮ ਹੋਣ 'ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।
• ਕਿਉਂ: ਸਪੱਸ਼ਟ ਕਾਰਨਾਂ ਕਰਕੇ ਇਹ ਦਿਲਚਸਪ ਸੀ—ਇਹ AppContainer ਨਾਲੋਂ ਕਿਸੇ ਵੀ ਸਾਫਟਵੇਅਰ ਲਈ ਵਧੇਰੇ ਅਨੁਕੂਲ ਹੈ, ਅਤੇ ਸੁਰੱਖਿਆ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਇਹ ਇੱਕ ਬਹੁਤ ਮਜ਼ਬੂਤ ਬਾਕਸ ਹੈ।
• ਕਿਉਂ ਨਹੀਂ: Codex ਨੂੰ ਉਪਭੋਗਤਾ ਦੇ ਅਸਲ ਕੋਡ, ਟੂਲਸ ਅਤੇ ਵਾਤਾਵਰਣ 'ਤੇ ਸਿੱਧਾ ਕੰਮ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਵੱਖਰੇ ਡਿਸਪੋਜ਼ੇਬਲ ਡੈਸਕਟੌਪ ਦੇ ਅੰਦਰ। ਇਸ ਵਿੱਚ ਇੱਕ ਬੁਨਿਆਦੀ ਉਤਪਾਦ ਸਮੱਸਿਆ ਵੀ ਸੀ: Windows ਸੈਂਡਬਾਕਸ 'Windows ਹੋਮ' ਸੰਸਕਰਣਾਂ 'ਤੇ ਉਪਲਬਧ ਹੀ ਨਹੀਂ ਹੈ।

ਲਾਜ਼ਮੀ ਇੰਟੈਗ੍ਰਿਟੀ ਕੰਟਰੋਲ (MIC) ਇੰਟੈਗ੍ਰਿਟੀ ਲੇਬਲਿੰਗ

• ਕੀ: Windows ਵਿੱਚ "ਇੰਟੈਗ੍ਰਿਟੀ ਲੈਵਲ" (ਜਿਵੇਂ ਕਿ ਲੋਅ, ਮੀਡੀਅਮ ਅਤੇ ਹਾਈ) ਦਾ ਸੰਕਲਪ ਹੈ, ਜੋ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਵਸਤੂਆਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ 'ਤੇ ਕਿੰਨਾ ਭਰੋਸਾ ਕਰਦਾ ਹੈ। ਬੁਨਿਆਦੀ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਘੱਟ-ਇੰਟੈਗ੍ਰਿਟੀ ਵਾਲਾ ਪ੍ਰੋਸੈਸ ਉੱਚ-ਇੰਟੈਗ੍ਰਿਟੀ ਵਾਲੀ ਵਸਤੂ 'ਤੇ ਨਹੀਂ ਲਿਖ ਸਕਦਾ, ਭਾਵੇਂ ਆਮ ACL ਇਸਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੋਵੇ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਘੱਟ-ਇੰਟੈਗ੍ਰਿਟੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਘੱਟ ਭਰੋਸੇਮੰਦ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ Windows ਇਸਨੂੰ ਸਾਧਾਰਨ ਮੀਡੀਅਮ-ਇੰਟੈਗ੍ਰਿਟੀ ਵਾਲੀਆਂ ਵਸਤੂਆਂ ਉੱਤੇ ਲਿਖਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਕਿ ਉਨ੍ਹਾਂ ਵਸਤੂਆਂ ਨੂੰ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਮੁੜ-ਲੇਬਲ ਨਾ ਕੀਤਾ ਗਿਆ ਹੋਵੇ।
• ਕਿਉਂ: MIC ਕਾਗਜ਼ਾਂ ਉੱਤੇ ਉਚਿਤ ਲੱਗ ਰਿਹਾ ਸੀ—Codex ਨੂੰ 'ਲੋਅ ਇੰਟੈਗ੍ਰਿਟੀ' 'ਤੇ ਚਲਾਓ, ਲਿਖਣਯੋਗ ਰੂਟਸ ਨੂੰ 'ਲੋਅ ਇੰਟੈਗ੍ਰਿਟੀ' ਵਜੋਂ ਮੁੜ-ਲੇਬਲ ਕਰੋ, ਅਤੇ Windows ਨੂੰ ਬਾਕੀ ਹਰ ਜਗ੍ਹਾ 'ਨੋ-ਰਾਈਟ' ਲਾਗੂ ਕਰਨ ਦਿਓ। ਇਸ ਨਾਲ ਸਾਨੂੰ ਇੱਕ ਅਸਲ OS ਮਕੈਨਿਜ਼ਮ ਦੇ ਨਾਲ ਇੱਕ ਗੈਰ-ਐਡਮਿਨ ਮਾਰਗ ਮਿਲ ਜਾਣਾ ਸੀ।
• ਕਿਉਂ ਨਹੀਂ: ACLs ਵਾਂਗ, ਇੰਟੈਗ੍ਰਿਟੀ ਲੇਬਲ ਅਸਲ ਹੋਸਟ ਫਾਈਲ-ਸਿਸਟਮ ਵਿੱਚ ਸੋਧ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਅਰਥ-ਭਰਪੂਰ ਤਬਦੀਲੀ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਵਿਆਪਕ ਹੈ। ਕਿਸੇ ਵਰਕਸਪੇਸ ਨੂੰ 'ਲੋਅ ਇੰਟੈਗ੍ਰਿਟੀ' ਵਜੋਂ ਮਾਰਕ ਕਰਨ ਦਾ ਮਤਲਬ ਸਿਰਫ ਇਹ ਨਹੀਂ ਹੈ ਕਿ "Codex ਇੱਥੇ ਲਿਖ ਸਕਦਾ ਹੈ।" ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਆਮ ਤੌਰ 'ਤੇ 'ਲੋਅ ਇੰਟੈਗ੍ਰਿਟੀ' ਪ੍ਰਕਿਰਿਆਵਾਂ ਉੱਥੇ ਲਿਖ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਅਸਲ ਡਿਵੈਲਪਰ ਮਸ਼ੀਨ 'ਤੇ, ਇਹ ਉਪਭੋਗਤਾ ਦੇ ਅਸਲ ਚੈੱਕਆਊਟ ਨੂੰ ਹੋਸਟ ਲਈ ਇੱਕ 'ਲੋਅ ਇੰਟੈਗ੍ਰਿਟੀ ਸਿੰਕ' ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਸੈਂਡਬਾਕਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਸਾਵਧਾਨੀ ਨਾਲ ਨਿਸ਼ਾਨਾ ਬਣਾ ਕੇ ਦਿੱਤੇ ਗਏ ACLs ਦੇ ਮੁਕਾਬਲੇ ਕਿਤੇ ਜ਼ਿਆਦਾ ਜੋਖਮ ਭਰਿਆ ਹੈ। ਭਾਵੇਂ 'ਮੀਡੀਅਮ-ਇੰਟੈਗ੍ਰਿਟੀ' ਡਿਵੈਲਪਰ ਟੂਲ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖਣ, ਪਰ ਵਰਕਸਪੇਸ ਦਾ ਬੁਨਿਆਦੀ ਭਰੋਸੇਯੋਗ ਮਾਡਲ ਅਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਗਿਆ ਹੈ ਜਿਸ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ ਅਤੇ ਸਹੀ ਠਹਿਰਾਉਣਾ ਹੋਰ ਵੀ ਔਖਾ ਹੈ।

ਸਾਰੇ ਵਿਕਲਪਾਂ ਨੂੰ ਅਸਵੀਕਾਰਨਯੋਗ ਮੰਨਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ Windows ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਇੱਕ ਵਧੀਆ Codex ਅਨੁਭਵ ਲਿਆਉਣ ਲਈ ਆਪਣਾ ਹੱਲ ਤਿਆਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ।

ਸਾਡੇ ਪਹਿਲੇ ਕਾਰਜਸ਼ੀਲ ਪ੍ਰੋਟੋਟਾਈਪ ਨੇ ਲੋੜੀਂਦੀ ਆਈਸੋਲੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ Windows ਸੰਕਲਪਾਂ ਅਤੇ ਸਾਧਨਾਂ ਦੇ ਸੁਮੇਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਸ਼ੁਰੂ ਤੋਂ ਹੀ, ਇੱਕ ਟੀਚਾ ਇਸਨੂੰ ਐਲੀਵੇਸ਼ਨ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਯੋਗ ਬਣਾਉਣਾ ਸੀ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ Codex ਨੂੰ ਸੈਂਡਬਾਕਸ ਸੈੱਟਅੱਪ ਕਰਨ ਜਾਂ ਚਲਾਉਣ ਲਈ ਉਪਭੋਗਤਾ ਤੋਂ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਨੀ ਪਵੇਗੀ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਦੋ ਚੀਜ਼ਾਂ 'ਤੇ ਉਚਿਤ ਸੀਮਾਵਾਂ ਕਿਵੇਂ ਲਗਾਈਆਂ ਜਾਣ: ਫਾਈਲ ਰਾਈਟਸ ਅਤੇ ਨੈੱਟਵਰਕ ਐਕਸੈਸ।

ਜੇਕਰ ਅਸੀਂ ਫਾਈਲ ਲਿਖਣ 'ਤੇ ਬਿਲਕੁਲ ਵੀ ਪਾਬੰਦੀ ਨਾ ਲਗਾਉਂਦੇ, ਤਾਂ ਇਹ ਸੁਰੱਖਿਆ ਦਾ ਮੁੱਦਾ ਹੁੰਦਾ। ਜੇਕਰ ਅਸੀਂ ਇਸ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੀਮਤ ਕਰ ਦਿੰਦੇ, ਤਾਂ ਸੈਂਡਬਾਕਸ ਉਪਭੋਗਤਾ ਦੀ ਉਤਪਾਦਕਤਾ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ, ਕਿਉਂਕਿ ਵਾਰ-ਵਾਰ ਮਨਜ਼ੂਰੀ ਮੰਗਣ ਦੀ ਲੋੜ ਪੈਂਦੀ। ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ Windows ਦੇ ਦੋ ਮਹੱਤਵਪੂਰਨ ਨਿਰਮਾਣ ਬਲਾਕਾਂ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ: SID ਅਤੇ ਰਾਈਟ-ਰਿਸਟ੍ਰਿਕਟਿਡ ਟੋਕਨ।

ਇੱਕ SID, ਜਾਂ ਸੁਰੱਖਿਆ ਪਛਾਣਕਰਤਾ, ਉਹ ਪਛਾਣ ਹੈ ਜਿਸਨੂੰ Windows ਇਜਾਜ਼ਤਾਂ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਹਰੇਕ ਉਪਭੋਗਤਾ ਦਾ ਇੱਕ SID ਹੁੰਦਾ ਹੈ, ਗਰੁੱਪਾਂ ਦੇ SID ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਸਿੰਗਲ ਲੌਗਇਨ ਸੈਸ਼ਨ ਨੂੰ ਵੀ ਆਪਣਾ SID ਮਿਲਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਮੌਜੂਦਾ ਲੌਗ-ਇਨ ਕੀਤੇ ਸੈਸ਼ਨ ਦਾ SID S-1-5-5-X-Y ਵਰਗਾ ਹੋ ਸਕਦਾ ਹੈ। ਸਥਾਨਕ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰਾਂ ਦੇ ਸਮੂਹ ਨੂੰ ਦਿੱਤਾ ਗਿਆ SID S-1-5-32-544 ਹੋ ਸਕਦਾ ਹੈ।

Windows ਤੁਹਾਨੂੰ ਸਿੰਥੈਟਿਕ SIDs ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਵੀ ਦਿੰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਅਸਲ ਉਪਭੋਗਤਾ ਦੇ ਅਨੁਸਾਰ ਨਹੀਂ ਹੁੰਦੇ ਪਰ ਫਿਰ ਵੀ ACLs (ਐਕਸੈਸ ਕੰਟਰੋਲ ਲਿਸਟਾਂ) ਵਿੱਚ ਦਿਖਾਈ ਦੇ ਸਕਦੇ ਹਨ, ਜੋ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਕਿ ਕੌਣ ਵਿਸ਼ੇਸ਼ ਫਾਈਲਾਂ ਜਾਂ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਪੜ੍ਹ/ਲਿਖ/ਚਲਾ ਸਕਦਾ ਹੈ। ਇਹ SID ਨੂੰ ਸਾਡੇ ਸੈਂਡਬਾਕਸ ਲਈ ਇੱਕ ਉਪਯੋਗੀ ਪ੍ਰਾਇਮਰੀ ਬਣਾਉਂਦਾ ਹੈ: ਅਸੀਂ ਮਸ਼ੀਨ 'ਤੇ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਵਿੱਚ ਦਖਲ ਦਿੱਤੇ ਬਿਨਾਂ, ਸਿਰਫ਼ Codex ਸੈਂਡਬਾਕਸ ਦੇ ਵਰਤਣ ਲਈ ਵਿਸ਼ੇਸ਼ SID ਬਣਾ ਸਕਦੇ ਹਾਂ।

Windows ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਟੋਕਨ ਅਜਿਹੀਆਂ ਸੁਰੱਖਿਆ ਵਸਤੂਆਂ ਹਨ ਜੋ ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਪਛਾਣ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਨ ਕਿ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਕ ਰਾਈਟ-ਰਿਸਟ੍ਰਿਕਟਿਡ ਟੋਕਨ ਪ੍ਰੋਸੈਸ ਟੋਕਨ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕਿਸਮ ਹੈ ਜੋ Windows ਨੂੰ 'ਲਿਖਣ' ਦੀਆਂ ਕਾਰਵਾਈਆਂ 'ਤੇ ਇੱਕ ਵਾਧੂ ਐਕਸੈਸ ਜਾਂਚ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ।

ਲਿਖਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਸਫਲ ਹੋਣ ਲਈ, ਦੋ ਜਾਂਚਾਂ ਪਾਸ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

1. ਆਮ ਉਪਭੋਗਤਾ ਪਛਾਣ (ਟੋਕਨ ਦੇ "ਮਾਲਕ") ਨੂੰ ਅਜਿਹਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ
2. ਟੋਕਨ ਦੀ ਰਿਸਟ੍ਰਿਕਟਿਡ SID ਸੂਚੀ ਵਿੱਚੋਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ SID ਨੂੰ ਵੀ ਐਕਸੈਸ ਦਿੱਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ

ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਹ ਜਾਂਚਾਂ ਸਾਨੂੰ ACLs ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਹ ਸਹੀ ਢੰਗ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਸੈਂਡਬਾਕਸ ਫਾਈਲ-ਸਿਸਟਮ ਨੂੰ ਕਿੱਥੇ ਸੋਧ ਸਕਦਾ ਹੈ, ਜਿਸ ਨੇ ਸਾਨੂੰ ਲਿਖਣ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਲੋੜੀਂਦੀ ਸੂਖਮਤਾ ਪ੍ਰਦਾਨ ਕੀਤੀ।

SIDs ਅਤੇ ਰਾਈਟ-ਰਿਸਟ੍ਰਿਕਟਿਡ ਟੋਕਨਾਂ ਦੇ ਨਾਲ, ਸਾਡਾ ਅਨ-ਐਲੀਵੇਟਿਡ ਸੈਂਡਬਾਕਸ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਸੀ:

1. ਸੈਂਡਬਾਕਸ ਸੈੱਟਅੱਪ ਨੇ ਸੈਂਡਬਾਕਸ-ਰਾਈਟ ਨਾਮਕ ਇੱਕ ਸਿੰਥੈਟਿਕ SID ਬਣਾਇਆ।
2. sandbox-write SID ਨੂੰ ਲਿਖਣ, ਚਲਾਉਣ ਅਤੇ ਮਿਟਾਉਣ ਦੀ ਪਹੁੰਚ ਦਿੱਤੀ ਗਈ ਸੀ
   1. ਮੌਜੂਦਾ ਕਾਰਜਸ਼ੀਲ ਡਾਇਰੈਕਟਰੀ
   2. config.toml ਵਿੱਚ ਕੌਂਫਿਗਰ ਕੀਤੇ ਕੋਈ ਵੀ ਵਾਧੂ writable_roots।
3. ਸੈਂਡਬਾਕਸ ਸੈੱਟਅੱਪ ਨੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਉਸੇ SID ਨੂੰ "ਲਿਖਣਯੋਗ ਦੇ ਅੰਦਰ ਸਿਰਫ਼ ਪੜ੍ਹਨਯੋਗ" (read-only within writable) ਸਥਾਨਾਂ ਜਿਵੇਂ ਕਿ ਇਹਨਾਂ ਲਈ ਲਿਖਣ ਦੀ ਐਕਸੈਸ ਤੋਂ ਇਨਕਾਰ ਕੀਤਾ:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex ਨੇ ਇੱਕ ਰਾਈਟ-ਰਿਸਟ੍ਰਿਕਟਿਡ ਟੋਕਨ ਦੇ ਅਧੀਨ ਕਮਾਂਡਾਂ ਲਾਂਚ ਕੀਤੀਆਂ ਜਿਸਦੀ ਰਿਸਟ੍ਰਿਕਟਿਡ SID ਸੂਚੀ ਵਿੱਚ ਹਰ ਕੋਈ, ਮੌਜੂਦਾ ਲੌਗ-ਇਨ ਕੀਤਾ ਹੋਇਆ ਸੈਸ਼ਨ SID, ਅਤੇ ਸੈਂਡਬਾਕਸ-ਰਾਈਟ ਸਿੰਥੈਟਿਕ SID ਸ਼ਾਮਲ ਹਨ।

ਇਸ ਪ੍ਰਵਾਹ ਨੇ ਫਾਈਲ ਲਿਖਣ ਨੂੰ ਸੀਮਤ ਕਰਨ ਦੇ ਮਸਲੇ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਹੱਲ ਕੀਤਾ ਅਤੇ ਇਹ ਉਮੀਦ ਭਰਪੂਰ ਜਾਪਦਾ ਸੀ। ਹੁਣ ਸਾਨੂੰ ਸੈਂਡਬਾਕਸ ਦੀ ਨੈੱਟਵਰਕ ਐਕਸੈਸ ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ ਇੱਕ ਹੱਲ ਦੀ ਲੋੜ ਸੀ।

ਨੈੱਟਵਰਕ ਐਕਸੈਸ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਸੈਂਡਬਾਕਸ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਹੈ; ਇਸ ਤੋਂ ਬਿਨਾਂ, ਕੋਈ ਵੀ ਖਤਰਨਾਕ ਕੋਡ ਮਸ਼ੀਨ ਤੋਂ ਇੰਟਰਨੈੱਟ ਤੱਕ ਡਾਟਾ ਚੋਰੀ ਕਰ ਸਕਦਾ ਹੈ। ਕਿਉਂਕਿ ਅਸੀਂ ਐਲੀਵੇਸ਼ਨ ਦੀ ਲੋੜ ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦੇ ਸੀ, ਸਾਡੇ ਕੋਲ ਨੈੱਟਵਰਕ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਖ਼ਤੀ ਨਾਲ ਰੋਕਣ ਲਈ ਸੀਮਤ ਵਿਕਲਪ ਸਨ। ਜਿਨ੍ਹਾਂ ਟੂਲਸ ਦੀ ਅਸੀਂ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ, ਜਿਵੇਂ ਕਿ 'Windows ਫਾਇਰਵਾਲ', ਆਮ ਤੌਰ 'ਤੇ ਐਡਮਿਨ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਤੋਂ ਬਿਨਾਂ ਸਥਾਪਿਤ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਸਨ।

Windows ਫਾਇਰਵਾਲ ਦੇ ਵਿਕਲਪ ਦੇ ਬਿਨਾਂ, ਅਸੀਂ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਸੀਮਤ ਕਰ ਦਿੱਤਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਕੰਟਰੋਲ ਕਰ ਸਕਦੇ ਸੀ। ਅਸੀਂ ਚਾਈਲਡ ਐਨਵਾਇਰਨਮੈਂਟ ਨੂੰ ਉਹਨਾਂ ਨੈੱਟਵਰਕ ਟੂਲਸ ਲਈ 'ਫੇਲ-ਕਲੋਜ਼ਡ' ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜੋ ਡਿਵੈਲਪਰ ਅਸਲ ਵਿੱਚ ਵਰਤਦੇ ਹਨ, ਤਾਂ ਜੋ ਗਿੱਟ ਕਮਾਂਡਾਂ, ਪੈਕੇਜ ਇੰਸਟਾਲਰ ਆਦਿ ਸੈਂਡਬਾਕਸ ਵਿੱਚ ਫੇਲ ਹੋ ਜਾਣ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਕਿਸੇ ਵੀ ਇੰਟਰਨੈੱਟ-ਮੁਖੀ ਕਾਰਵਾਈ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣੀ ਪਵੇ। ਵਿਚਾਰ ਇਹ ਸੀ ਕਿ ਸਪੱਸ਼ਟ ਰਸਤਿਆਂ ਨੂੰ ਬੰਦ ਕੀਤਾ ਜਾਵੇ: ਪ੍ਰੌਕਸੀ-ਸਚੇਤ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੱਕ ਡੈੱਡ ਐਂਡਪੁਆਇੰਟ 'ਤੇ ਭੇਜਣਾ, ਗਿੱਟ ਦੇ HTTP(S) ਟ੍ਰਾਂਸਪੋਰਟ ਨੂੰ ਵੀ ਅਜਿਹਾ ਹੀ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਨਾ, ਅਤੇ SSH ਰਾਹੀਂ ਗਿੱਟ ਨੂੰ ਤੁਰੰਤ ਫੇਲ ਕਰਨਾ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ PATH ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਛੋਟੀ denybin ਡਾਇਰੈਕਟਰੀ ਜੋੜੀ ਅਤੇ PATHEXT ਨੂੰ ਮੁੜ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਤਾਂ ਜੋ ਅਸਲ ਬਾਈਨਰੀਆਂ ਤੋਂ ਪਹਿਲਾਂ ਸਟਬ SSH ਅਤੇ SCP ਸਕ੍ਰਿਪਟਾਂ ਕੰਮ ਕਰਨ।

ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਕੁਝ ਖਾਸ ਐਨਵਾਇਰਨਮੈਂਟ ਓਵਰਰਾਈਡ ਹਨ ਜੋ ਅਸੀਂ ਨੈੱਟਵਰਕ ਐਕਸੈਸ ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ ਵਰਤੇ ਹਨ:

• 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 ਨਾਲ ਸਬੰਧਤ ਹਨ ਜੋ ਸਿਰਫ ਸੈਂਡਬਾਕਸ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
• ਬਦਲਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਨਿਯਮ: ਫਾਈਲ-ਅਧਾਰਿਤ ਪਾਬੰਦੀਆਂ ਲਈ ACL 'ਤੇ ਨਿਰਭਰਤਾ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੈਂਡਬਾਕਸ ਦੇ ਨਿਯਮਾਂ ਨੂੰ ਬਦਲਣਾ ਮਹਿੰਗਾ ਅਤੇ ਗੁੰਝਲਦਾਰ ਹੈ। ਜਦੋਂ ਕਿ macOS 'ਤੇ, ਅਸੀਂ ਸੀਟਬੈਲਟ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਲਈ ਵਰਤੀ ਜਾਣ ਵਾਲੀ .sbpl ਫਾਈਲ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਾਂ, Windows ਸੈਂਡਬਾਕਸ ਵਿੱਚ ACL ਨੂੰ ਐਡਜਸਟ ਕਰਨ ਲਈ ਇੱਕ ਸੁਸਤ ਅਤੇ ਗੁੰਝਲਦਾਰ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
• ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰ ਹੈ। ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇਹ "ਸਲਾਹਕਾਰੀ" ਸੀ ਅਤੇ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਪ੍ਰੋਗਰਾਮਾਂ ਦੁਆਰਾ ਬਾਈਪਾਸ ਕੀਤੀ ਜਾ ਸਕਦੀ ਸੀ ਜੋ ਆਪਣਾ ਨੈੱਟਵਰਕਿੰਗ ਸਟੈਕ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਇਹ ਕਿਸੇ ਖਤਰਨਾਕ ਕੋਡ ਦਾ ਮੁਕਾਬਲਾ ਕਰਨ ਲਈ ਨਹੀਂ ਬਣਾਈ ਗਈ ਸੀ।

ਪਹਿਲੇ ਤਿੰਨ ਮੁੱਦੇ ਇੱਕ ਅਜਿਹੇ ਕਸਟਮ ਸੈਂਡਬਾਕਸ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦੇ ਸੁਭਾਵਿਕ ਹਿੱਸੇ ਹਨ ਜੋ ਏਜੰਟ-ਅਧਾਰਿਤ ਕਾਰਜਾਂ ਲਈ ਲਚਕਦਾਰ ਹੋਵੇ। ਹਾਲਾਂਕਿ, ਨੈੱਟਵਰਕ ਰੋਕਥਾਮ ਦੀ ਕਹਾਣੀ ਵੱਖਰੀ ਸੀ।

ਕਿਸੇ ਖਤਰਨਾਕ ਏਜੰਟ ਦੁਆਰਾ ਵਾਤਾਵਰਣ-ਅਧਾਰਿਤ ਨੈੱਟਵਰਕ ਰੋਕਥਾਮ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਬਾਈਪਾਸ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੋਣ ਤੋਂ ਇਲਾਵਾ, ਬਹੁਤ ਸਾਰਾ ਚੰਗੀ ਨੀਅਤ ਵਾਲਾ ਕੋਡ/ਬਾਈਨਰੀਆਂ ਵੀ ਇਸ ਨੂੰ ਸਿਰਫ਼ ਇਸ ਲਈ ਬਾਈਪਾਸ ਕਰ ਦੇਣਗੀਆਂ ਜੇਕਰ ਉਹ ਵਾਤਾਵਰਣ ਦੇ ਪ੍ਰੌਕਸੀ ਵੇਰੀਏਬਲਜ਼ ਨੂੰ ਨਹੀਂ ਮੰਨਦੇ, ਜਾਂ ਜੇਕਰ ਉਹ ਆਪਣਾ ਸਾਕਟ-ਅਧਾਰਿਤ ਨੈੱਟਵਰਕ ਕੋਡ ਲਾਗੂ ਕਰਦੇ ਹਨ। ਸਾਨੂੰ ਮਹਿਸੂਸ ਹੋਇਆ ਕਿ ਇੱਕ ਬਿਹਤਰ ਸੈਂਡਬਾਕਸ ਮੋਡ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਲਈ ਇਹ ਪਹਿਲੂ ਕਾਫ਼ੀ ਸੀ।

ਬਿਹਤਰ ਨੈੱਟਵਰਕ ਰੋਕਥਾਮ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਅਸੀਂ Windows ਫਾਇਰਵਾਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ, ਜੋ ਸਾਨੂੰ ਉਪਭੋਗਤਾਵਾਂ ਜਾਂ ਪ੍ਰੋਗਰਾਮਾਂ ਲਈ ਬਾਹਰੀ ਨੈੱਟਵਰਕ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਸੀਂ ਕੁਝ ਕਾਰਨਾਂ ਕਰਕੇ ਅਜਿਹਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਨਹੀਂ ਬਣਾ ਸਕੇ ਜੋ ਸਿਰਫ਼ Codex ਹਾਰਨੈੱਸ ਦੁਆਰਾ ਚਲਾਈਆਂ ਗਈਆਂ ਕਮਾਂਡਾਂ 'ਤੇ ਲਾਗੂ ਹੋਵੇ:

• Windows ਕਿਸੇ ਰਿਸਟ੍ਰਿਕਟਿਡ ਟੋਕਨ ਦੀ 'ਗੈਰ-ਪ੍ਰਿੰਸੀਪਲ ਪਛਾਣ' ਨਾਲ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨੂੰ ਮੇਲਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਅਜਿਹਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲਾਗੂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸੀ ਜੋ "ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਟੋਕਨ 'ਤੇ ਲਾਗੂ ਹੋਵੇ ਜਿਸਦੀ ਰਿਸਟ੍ਰਿਕਟਿਡ SID ਸੂਚੀ ਵਿੱਚ ਸਾਡਾ ਸਿੰਥੈਟਿਕ SID ਸ਼ਾਮਲ ਹੋਵੇ।"
• ਹਾਲਾਂਕਿ ਅਸੀਂ ਇੱਕ ਅਜਿਹਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਣਾ ਸਕਦੇ ਸੀ ਜੋ ਕਿਸੇ ਖਾਸ ਬਾਈਨਰੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ, ਪਰ ਇਹ ਸਾਨੂੰ ਸਿਰਫ codex.exe ਲਈ ਹੀ ਨੈੱਟਵਰਕਿੰਗ ਸੀਮਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੋਵੇਗਾ ਜੋ ਏਜੰਟ ਉਪਭੋਗਤਾ ਦੀ ਤਰਫੋਂ ਚਲਾਉਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ Git ਜਾਂ Python ਪ੍ਰਕਿਰਿਆਵਾਂ।
• ਫਾਇਰਵਾਲ ਦੇ ਹੋਰ ਮਾਪਦੰਡ ਵੀ ਗਲਤ ਸਨ। ਯੂਜ਼ਰ-ਸਕੋਪਡ (User-scoped) ਨਿਯਮ ਅਜੇ ਵੀ ਅਨ-ਐਲੀਵੇਟਿਡ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਅਸਲ Windows ਉਪਭੋਗਤਾ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਸਨ, ਨਾ ਕਿ ਸਿਰਫ ਰਿਸਟ੍ਰਿਕਟਿਡ ਚਾਈਲਡ ਨਾਲ। ਪ੍ਰੋਗਰਾਮ-ਪਾਥ ਨਿਯਮ ਬਹੁਤ ਵਿਆਪਕ ਸਨ: ਉਹ ਆਮ ਤੌਰ 'ਤੇ codex.exe ਜਾਂ python.exe ਨੂੰ ਬਲੌਕ ਕਰ ਸਕਦੇ ਸਨ, ਪਰ python.exe ਦੇ ਇਸ ਇੱਕ ਸੈਂਡਬਾਕਸ ਕੀਤੇ ਵਰਤੋਂ ਨੂੰ ਨਹੀਂ। ਪੋਰਟ- ਜਾਂ ਐਡਰੈੱਸ-ਅਧਾਰਿਤ ਨਿਯਮ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗਲਤ ਨੀਤੀ ਸਨ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਪੋਰਟ 443 ਨੂੰ ਬਲੌਕ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ; ਅਸੀਂ ਇਸ ਖਾਸ ਰਿਸਟ੍ਰਿਕਟਿਡ ਪ੍ਰੋਸੈਸ ਟ੍ਰੀ ਲਈ ਕਿਸੇ ਵੀ ਕਿਸਮ ਦੀ ਬਾਹਰੀ ਪਹੁੰਚ ਨੂੰ ਬਲੌਕ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ।

ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਸਾਡੀਆਂ ਸੈਂਡਬਾਕਸਡ ਕਮਾਂਡਾਂ 'ਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲਾਗੂ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਉਨ੍ਹਾਂ ਨੂੰ "ਅਸਲ" ਉਪਭੋਗਤਾ ਵਜੋਂ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਵੱਖਰੇ ਪ੍ਰਿੰਸੀਪਲ ਵਜੋਂ ਚਲਾਉਣ ਦੀ ਲੋੜ ਸੀ। ਇਹ ਪਹੁੰਚ ਸਾਨੂੰ ਇੱਕ ਨਵੇਂ ਰਸਤੇ 'ਤੇ ਲੈ ਗਈ, ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਆਪਣੀ "ਨੋ ਐਲੀਵੇਸ਼ਨ" ਵਾਲੀ ਸ਼ਰਤ ਨੂੰ ਆਸਾਨ ਕਰ ਦਿੱਤਾ।

ਸੈਂਡਬੌਕਸ ਦਾ ਅਗਲਾ ਸੰਸਕਰਣ, ਜੋ ਕਿ ਸਾਡੀ ਮੌਜੂਦਾ ਕਾਰਜ-ਵਿਧੀ ਹੈ, ਨੂੰ ਸੈੱਟਅੱਪ ਦੇ ਸਮੇਂ ਉੱਚੇ ਐਡਮਿਨ ਅਧਿਕਾਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ ਮੈਂ ਇਸਨੂੰ “ਐਲੀਵੇਟਿਡ ਸੈਂਡਬੌਕਸ” ਵਜੋਂ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹਾਂ। ਉਸ ਸੀਮਾ 'ਤੇ ਜਿੱਥੇ Codex ਸਿਸਟਮ ਉੱਤੇ ਇੱਕ ਕਮਾਂਡ ਚਲਾਉਂਦਾ ਹੈ, ਉੱਥੇ ਐਲੀਵੇਟਿਡ ਸੈਂਡਬੌਕਸ ਬਿਨਾਂ-ਐਲੀਵੇਸ਼ਨ ਵਾਲੇ ਸੈਂਡਬੌਕਸ ਵਾਂਗ ਹੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਇਹ ਅਜੇ ਵੀ ਇੱਕ ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ ਦੇ ਅਧੀਨ ਚਾਈਲਡ ਪ੍ਰੋਸੈਸ ਚਲਾਉਂਦਾ ਹੈ—ਇਸੇ ਤਰ੍ਹਾਂ [Everyone, Logon, Synthetic] ਦੀ ਸਮਾਨ ਪ੍ਰਤਿਬੰਧਿਤ SID ਸੂਚੀ ਵਾਲਾ ਇੱਕ write_restricted ਟੋਕਨ—ਹਾਲਾਂਕਿ, ਇਸ ਟੋਕਨ ਦਾ ਮੁੱਖ ਕਰਤਾ ਹੁਣ ਅਸਲ Windows ਉਪਭੋਗਤਾ ਨਹੀਂ ਹੈ, ਬਲਕਿ Codex ਦੁਆਰਾ ਖੁਦ ਬਣਾਏ ਗਏ ਦੋ ਸਥਾਨਕ ਉਪਭੋਗਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ:

• CodexSandboxOffline (ਜਿਸ 'ਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ)
• CodexSandboxOnline (ਜਿਸ 'ਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੇ)

ਇਹ ਪ੍ਰਤੀਤ ਹੁੰਦੀ ਛੋਟੀ ਜਿਹੀ ਵਿਸ਼ੇਸ਼ਤਾ ਅਸਲ ਵਿੱਚ ਸੈਂਡਬੌਕਸ ਲਈ, ਇਸਦੀ ਵਰਤੋਂ ਕੌਣ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਸੈੱਟਅੱਪ ਅਤੇ ਰਨਟਾਈਮ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀ ਗੁੰਝਲਦਾਰਤਾ ਲਈ ਬਹੁਤ ਵੱਡੇ ਪ੍ਰਭਾਵ ਰੱਖਦੀ ਹੈ।

ਇਹ ਦ੍ਰਿਸ਼ਟੀਗਤ ਰੂਪ ਵਿੱਚ ਬਿਨਾਂ-ਐਲੀਵੇਸ਼ਨ ਵਾਲੇ ਪ੍ਰੋਟੋਟਾਈਪ ਦੇ ਸਮਾਨ ਹੈ, ਜਿਸ ਵਿੱਚ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਅਤੇ ਇੱਕ ਸਮਰਪਿਤ Windows ਉਪਭੋਗਤਾ ਦੀ ਸ਼ੁਰੂਆਤ ਕੀਤੀ ਗਈ ਹੈ, ਜੋ ਅਸਲ ਵਿੱਚ ਕਮਾਂਡਾਂ ਚਲਾਉਂਦਾ ਹੈ। (ਹਾਲਾਂਕਿ, ਇਹਨਾਂ ਨਵੀਆਂ ਧਾਰਨਾਵਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੈਂਡਬੌਕਸ ਦੁਆਰਾ ਕਮਾਂਡਾਂ ਚਲਾਉਣ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੈੱਟਅੱਪ ਦਾ ਕੰਮ ਹੁਣ ਜ਼ਿਆਦਾ ਹੈ।)

ਬਿਨਾਂ-ਐਲੀਵੇਸ਼ਨ ਵਾਲੇ ਸੈਂਡਬੌਕਸ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਸੈੱਟਅੱਪ ਪੜਾਅ ਸੀ, ਪਰ ਇਹ ਮੁਕਾਬਲਤਨ ਛੋਟਾ ਸੀ:

• ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਇੱਕ ਸਿੰਥੈਟਿਕ SID ਬਣਾਉਣਾ
• ਸੈਂਡਬੌਕਸ-ਰਾਈਟ ਸਿੰਥੈਟਿਕ SID ਲਈ ACLs ਲਾਗੂ ਕਰਨਾ

ਹਾਲਾਂਕਿ, ਐਲੀਵੇਟਿਡ ਸੈਂਡਬੌਕਸ ਕੋਲ ਕਰਨ ਲਈ ਹੋਰ ਬਹੁਤ ਕੁਝ ਹੈ।

• ਇੱਕ ਸਿੰਥੈਟਿਕ SID ਬਣਾਉਣਾ, ਜੇਕਰ ਪਹਿਲਾਂ ਤੋਂ ਨਹੀਂ ਬਣਿਆ ਹੈ
• ਔਨਲਾਈਨ ਅਤੇ ਔਫਲਾਈਨ ਸੈਂਡਬੌਕਸ ਉਪਭੋਗਤਾ ਬਣਾਉਣਾ, ਜੇਕਰ ਪਹਿਲਾਂ ਤੋਂ ਨਹੀਂ ਬਣੇ ਹਨ
• ਨਵੇਂ ਬਣਾਏ ਗਏ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰਨਾ ਅਤੇ Windows ਡੇਟਾ ਪ੍ਰੋਟੈਕਸ਼ਨ API (DPAPI) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਜਿਹੀ ਜਗ੍ਹਾ 'ਤੇ ਐਨਕ੍ਰਿਪਟ ਕਰਨਾ ਜਿੱਥੇ ਸੈਂਡਬੌਕਸ ਉਪਭੋਗਤਾ ਉਹਨਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਪੜ੍ਹ ਨਾ ਸਕਣ
• ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਣਾਉਣਾ ਜੋ CodexSandboxOffline ਉਪਭੋਗਤਾ ਲਈ ਸਾਰੀ ਆਊਟਬਾਊਂਡ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਨੂੰ ਰੋਕਦੇ ਹਨ ਜਾਂ, ਜੇਕਰ ਉਹ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ ਕਿ ਉਹ ਸਹੀ ਹਨ

ਸੈੱਟਅੱਪ ਪੜਾਅ ਵਿੱਚ ਇੱਕ ਵਾਧੂ ਪੇਚੀਦਗੀ ਹੈ। Codex ਦੇ ਸੈਂਡਬੌਕਸ ਤੋਂ ਇਹ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਉਸ ਕੋਲ ਅਸਲ Windows ਉਪਭੋਗਤਾ ਦੇ ਬਰਾਬਰ ਰੀਡ ਐਕਸੈਸ ਹੋਵੇ। ਬਿਨਾਂ-ਐਲੀਵੇਸ਼ਨ ਵਾਲੇ ਸੈਂਡਬੌਕਸ ਵਿੱਚ, ਜਿੱਥੇ ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ ਦਾ ਮੁੱਖ SID Windows ਉਪਭੋਗਤਾ ਸੀ, ਇਹ ਪ੍ਰਾਪਤ ਕਰ ਲਿਆ ਗਿਆ ਸੀ। ਹਾਲਾਂਕਿ, ਜਦੋਂ ਮੁੱਖ ਕਰਤਾ ਇੱਕ ਨਵਾਂ CodexSandbox ਉਪਭੋਗਤਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਆਪਣੇ ਆਪ ਨਹੀਂ ਮਿਲਦਾ। Windows ਉੱਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਬੰਧਿਤ ਡਾਇਰੈਕਟਰੀਆਂ "ਪ੍ਰਮਾਣਿਤ ਉਪਭੋਗਤਾਵਾਂ" ਨੂੰ ਪੜ੍ਹਨ/ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਪ੍ਰਮੁੱਖ ਉਦਾਹਰਣ ਉਪਭੋਗਤਾ ਦੀ ਪ੍ਰੋਫਾਈਲ ਡਾਇਰੈਕਟਰੀ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ, Windows ਉਪਭੋਗਤਾ ਦੂਜੇ Windows ਉਪਭੋਗਤਾਵਾਂ ਦੀਆਂ ਪ੍ਰੋਫਾਈਲ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੇ, ਇਸ ਲਈ ਕਈ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸਧਾਰਨ ਫਾਈਲ ਰੀਡਿੰਗ ਵੀ ਅਸਫਲ ਹੋ ਜਾਵੇਗੀ।

ਇਸ ਨਾਲ ਨਜਿੱਠਣ ਲਈ, ਅਸੀਂ ਸੈਂਡਬੌਕਸ ਸੈੱਟਅੱਪ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਇੱਕ ਹੋਰ ਪਰਤ ਜੋੜੀ ਹੈ—ਸੈਂਡਬੌਕਸ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਰੀਡ ACL ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਜਿੱਥੇ ਅਜਿਹੇ ACLs ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਣ ਵਜੋਂ, ਕੁਝ ਆਮ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ Windows ਡਾਇਰੈਕਟਰੀਆਂ ਲਈ:

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

ਕਿਉਂਕਿ ਡਾਇਰੈਕਟਰੀਆਂ ਦੀ ਇਹ ਸੂਚੀ ਸਭ ਤੋਂ ਵਧੀਆ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਅਧਾਰਤ ਹੈ ਅਤੇ ਹਰੇਕ 'ਤੇ ACLs ਇੰਸਟਾਲ ਕਰਨਾ ਕਾਫ਼ੀ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ, ਅਸੀਂ ਇਸ ਲੋਜਿਕ ਨੂੰ ਅਸਿੰਕ੍ਰੋਨਸਲੀ ਚਲਾਉਂਦੇ ਹਾਂ ਤਾਂ ਜੋ ਸੈਂਡਬੌਕਸ ਸੈੱਟਅੱਪ ਪੜਾਅ, ਜੋ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਰੁਕਾਵਟ ਬਣਦਾ ਹੈ, ਨੂੰ ਇਹਨਾਂ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਨਾ ਕਰਨੀ ਪਵੇ।

ਅਸੀਂ ਸੈੱਟਅੱਪ ਲੋਜਿਕ ਨੂੰ ਇਸਦੇ ਆਪਣੇ ਬਾਈਨਰੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਹੈ, ਜਿਸਦਾ ਇੱਕ ਕਾਰਨ ਸਿਰਫ਼ ਲੋੜ ਪੈਣ 'ਤੇ ਹੀ UAC ਸੀਮਾ ਨੂੰ ਪਾਰ ਕਰਨਾ ਸੀ। ਪਰ ਇਸਦਾ ਡੂੰਘਾ ਕਾਰਨ ਆਰਕੀਟੈਕਚਰਲ ਸੀ: ਸੈਂਡਬੌਕਸ ਸੈੱਟਅੱਪ ਦਾ ਕੰਮ codex.exe ਨਾਲੋਂ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਵੱਖਰਾ ਹੈ। ਸੈਂਡਬੌਕਸ ਸੈੱਟਅੱਪ ਲੋਜਿਕ ਨੂੰ ਇੱਕ ਸਮਰਪਿਤ ਬਾਈਨਰੀ ਵਿੱਚ ਰੱਖਣ ਨਾਲ codex.exe ਇੱਕ ਸਾਧਾਰਨ, ਬਿਨਾਂ-ਐਲੀਵੇਸ਼ਨ ਵਾਲੇ ਹਾਰਨੈੱਸ ਵਜੋਂ ਰਹਿ ਸਕਿਆ; ਇਸਨੇ ਸਿਰਫ਼-ਵਿੰਡੋਜ਼ ਵਾਲੀ ਸੈੱਟਅੱਪ ਮਸ਼ੀਨਰੀ ਨੂੰ ਦੂਜੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ codex.exe ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਤੋਂ ਰੋਕਿਆ; ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਸੈੱਟਅੱਪ ਕਾਰਜਾਂ ਨੂੰ ਮੁੱਖ ਪ੍ਰਕਿਰਿਆ ਦੇ ਜੀਵਨ ਕਾਲ ਤੋਂ ਵੱਖ ਕੀਤਾ; ਅਤੇ ਸਾਨੂੰ ਸੈਂਡਬੌਕਸ ਲਈ ਲੋੜੀਂਦੇ ਵੱਖ-ਵੱਖ ਸੈੱਟਅੱਪ ਮਾਰਗਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਇੱਕ ਸਾਂਝੀ ਥਾਂ ਦਿੱਤੀ।

Windows ਉਪਭੋਗਤਾ ਅਤੇ ਟੋਕਨ ਲੌਗਇਨ ਸੀਮਾਵਾਂ ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕੇ ਕਰਕੇ, ਅਸੀਂ ਇੱਕ ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ ਬਣਾਉਣਾ ਅਤੇ ਇਸਦੇ ਅਧੀਨ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਨਾ ਜਾਰੀ ਨਹੀਂ ਰੱਖ ਸਕੇ ਜਿਵੇਂ ਅਸੀਂ ਬਿਨਾਂ-ਐਲੀਵੇਸ਼ਨ ਵਾਲੇ ਸੈਂਡਬੌਕਸ ਵਿੱਚ ਕਰ ਸਕਦੇ ਸੀ। ਕਮਾਂਡਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਇੱਕ ਵੱਖਰੇ ਵਿੰਡੋਜ਼ ਉਪਭੋਗਤਾ ਵਜੋਂ ਚਲਾਉਣ ਲਈ, ਸਾਡਾ ਪਹਿਲਾ ਵਿਚਾਰ ਹੇਠਾਂ ਦਿੱਤੇ ਪ੍ਰਵਾਹ ਬਾਰੇ ਸੀ:

• codex.exe ਅਸਲ Windows ਉਪਭੋਗਤਾ ਵਜੋਂ ਚੱਲਦਾ ਹੈ। ਫਿਰ, ਇੱਕ ਕ੍ਰਮ ਵਿੱਚ, Codex:
  • ਸੈਂਡਬੌਕਸ ਉਪਭੋਗਤਾ ਲਈ LogonUserW(...) ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।
  • ਉਸ ਸੈਂਡਬੌਕਸ-ਉਪਭੋਗਤਾ ਟੋਕਨ 'ਤੇ CreateRestrictedToken(...) ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।
  • ਉਸ ਪ੍ਰਤਿਬੰਧਿਤ ਸੈਂਡਬੌਕਸ-ਉਪਭੋਗਤਾ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਅੰਤਿਮ ਚਾਈਲਡ ਪ੍ਰੋਸੈਸ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਲਈ CreateProcessAsUserW(...) ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।

ਵਿਹਾਰਕ ਤੌਰ 'ਤੇ, ਇਹ ਲੋੜੀਂਦਾ ਪ੍ਰਵਾਹ CreateProcessAsUserW(...) 'ਤੇ ਮਿਲੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਰੁਕਾਵਟ ਕਾਰਨ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਿਆ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ codex.exe ਸੈਂਡਬੌਕਸ ਉਪਭੋਗਤਾ ਲਈ ਇੱਕ ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ ਤਾਂ ਬਣਾ ਸਕਦਾ ਸੀ, ਪਰ ਇਹ ਸੀਮਾ ਦੇ ਅਸਲ-ਉਪਭੋਗਤਾ ਵਾਲੇ ਪਾਸੇ ਤੋਂ ਉਸ ਟੋਕਨ ਦੇ ਨਾਲ ਇੱਕ ਚਾਈਲਡ ਪ੍ਰੋਸੈਸ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਲਾਂਚ ਨਹੀਂ ਕਰ ਸਕਿਆ। ਸਾਨੂੰ ਇੱਕ ਅਜਿਹੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਸੀ ਜੋ ਪਹਿਲਾਂ ਹੀ ਸੈਂਡਬੌਕਸ ਉਪਭੋਗਤਾ ਵਜੋਂ ਚੱਲ ਰਹੀ ਹੋਵੇ—ਇਸ ਨਾਲ ਪ੍ਰਤਿਬੰਧਿਤ ਕਰਨ ਵਾਲਾ ਪੜਾਅ ਅਤੇ ਅੰਤਿਮ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸ਼ੁਰੂਆਤ ਅਸਲ-ਉਪਭੋਗਤਾ ਵਾਲੇ ਪਾਸੇ ਦੀ ਬਜਾਏ ਸੈਂਡਬੌਕਸ-ਉਪਭੋਗਤਾ ਵਾਲੇ ਪਾਸੇ ਸੰਭਵ ਹੋ ਸਕਦੀ ਸੀ।

ਇਸ ਲੋੜ ਨੇ codex-command-runner.exe ਨੂੰ ਜਨਮ ਦਿੱਤਾ, ਜੋ ਕਿ ਇੱਕ ਨਵਾਂ ਬਾਈਨਰੀ ਹੈ ਜਿਸਦਾ ਇਕੋ-ਇਕ ਕੰਮ ਇੱਕ ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ ਤਿਆਰ ਕਰਨਾ ਅਤੇ ਮੰਗੀ ਗਈ ਕਮਾਂਡ ਨੂੰ ਚਲਾਉਣਾ ਹੈ। codex.exe ਨੂੰ ਪੂਰਾ ਪ੍ਰਵਾਹ ਖੁਦ ਕਰਨ (ਅਸਲ ਉਪਭੋਗਤਾ → ਸੈਂਡਬੌਕਸ ਉਪਭੋਗਤਾ → ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ → ਚਾਈਲਡ ਪ੍ਰੋਸੈਸ) ਲਈ ਕਹਿਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਇਸ ਪ੍ਰਵਾਹ ਨੂੰ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡ ਦਿੱਤਾ ਹੈ:

ਭਾਗ 1

• codex.exe ਅਜੇ ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ, codex-command-runner.exe ਨੂੰ ਸੈਂਡਬੌਕਸ ਉਪਭੋਗਤਾ ਵਜੋਂ ਲਾਂਚ ਕਰਨ ਲਈ CreateProcessWithLogonW(...) ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।

ਭਾਗ 2

• ਰਨਰ ਦੇ ਅੰਦਰ, OpenProcessToken(GetCurrentProcess(), ...) ਰਨਰ ਦੇ ਆਪਣੇ ਟੋਕਨ ਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ, ਜੋ ਪਹਿਲਾਂ ਹੀ ਸੈਂਡਬੌਕਸ ਉਪਭੋਗਤਾ ਨਾਲ ਸਬੰਧਤ ਹੈ।
• ਰਨਰ ਸੈਂਡਬੌਕਸ ਲੌਗਇਨ SID ਕੱਢਣ ਲਈ GetTokenInformation(...) ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਫਿਰ ਅੰਤਿਮ ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ ਬਣਾਉਣ ਲਈ CreateRestrictedToken(...) ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।
• ਅਜੇ ਵੀ ਰਨਰ ਦੇ ਅੰਦਰ ਹੀ, ਇਹ ਅਸਲ ਚਾਈਲਡ ਪ੍ਰੋਸੈਸ ਨੂੰ ਲਾਂਚ ਕਰਨ ਲਈ ਉਸ ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ ਨਾਲ CreateProcessAsUserW(...) ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।

ਅਲਬਰਟ ਆਈਨਸਟਾਈਨ ਨੇ ਕਿਹਾ ਸੀ, “ਹਰ ਚੀਜ਼ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸਰਲ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਉਸ ਤੋਂ ਵੱਧ ਸਰਲ ਨਹੀਂ।” ਉਸੇ ਭਾਵਨਾ ਨਾਲ, ਸਾਡੇ ਡਿਜ਼ਾਈਨ ਨੇ ਹਰੇਕ ਸਮੱਸਿਆ ਨੂੰ ਢੁਕਵੇਂ ਰੂਪ ਵਿੱਚ ਹੱਲ ਕੀਤਾ ਹੈ। ਅੰਤਿਮ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਉਹ ਚਾਰ ਪਰਤਾਂ ਹਨ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਕਵਰ ਕੀਤੀਆਂ ਹਨ:

• codex.exe ਖੁਦ
• codex-windows-sandbox-setup.exe ਸੈੱਟਅੱਪ ਨਾਲ ਸਬੰਧਤ ਸਾਰੇ ਐਲੀਵੇਟਿਡ ਕੰਮਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ
• codex-command-runner.exe ਪ੍ਰਤਿਬੰਧਿਤ ਟੋਕਨ ਕਮਾਂਡਾਂ ਚਲਾਉਣ ਲਈ
• ਚਾਈਲਡ ਪ੍ਰੋਸੈਸ

ਜਦੋਂ ਮੈਂ ਪਹਿਲੀ ਵਾਰ ਇਸ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ, ਤਾਂ ਮੈਨੂੰ ਇਸ ਗੱਲ ਦਾ ਪੱਕਾ ਅਹਿਸਾਸ ਨਹੀਂ ਸੀ ਕਿ ਇਹ ਕਿੱਥੇ ਜਾ ਕੇ ਖਤਮ ਹੋਵੇਗਾ। ਮੇਰੀ ਪਹੁੰਚ Codex ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਵਿਚਕਾਰਲੀ ਸੀਮਾ ਵਿੱਚ ਸੈਂਡਬੌਕਸਿੰਗ ਸਮਰੱਥਾ ਨੂੰ ਲਾਗੂ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਸੀ। ਇਹ ਪਹੁੰਚ MacOs ਅਤੇ Linux ਉੱਤੇ Codex ਦੇ ਸੈਂਡਬੌਕਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨਾਲ ਕਾਫ਼ੀ ਮਿਲਦੀ-ਜੁਲਦੀ ਹੈ।

ਜਿਵੇਂ-ਜਿਵੇਂ ਮੈਂ ਵਿੰਡੋਜ਼ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਵਿਸ਼ੇਸ਼ ਟੂਲਸ ਬਾਰੇ ਹੋਰ ਸਿੱਖਿਆ, ਅਤੇ ਸੁਰੱਖਿਆ ਤੇ ਵਰਤੋਂ ਵਿੱਚ ਆਸਾਨੀ ਦੇ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਉਣ ਵਾਲੇ ਦਰਜਨਾਂ ਫੈਸਲਿਆਂ ਰਾਹੀਂ, ਇਹ ਸਿਸਟਮ ਆਪਣੇ ਮੌਜੂਦਾ ਰੂਪ ਤੱਕ ਪਹੁੰਚਿਆ—ਜਿਸ ਵਿੱਚ ਕਈ ਬਾਈਨਰੀਆਂ, ਕਸਟਮ ਉਪਭੋਗਤਾ, ਫਾਇਰਵਾਲ ਨਿਯਮ, ਇੱਕ ਐਲੀਵੇਟਿਡ ਸੈੱਟਅੱਪ ਪੜਾਅ, ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਸ਼ਾਮਲ ਹੈ।

ਇਹ ਕੋਈ ਖਾਸ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਸਿਸਟਮ ਨਹੀਂ ਹੈ, ਪਰ ਗੁੰਝਲਦਾਰਤਾ ਦਾ ਹਰ ਹਿੱਸਾ ਜ਼ਰੂਰਤ ਅਨੁਸਾਰ ਜੋੜਿਆ ਗਿਆ ਸੀ, ਤਾਂ ਜੋ ਇੱਕ ਅਜਿਹਾ ਸੈਂਡਬੌਕਸ ਬਣਾਇਆ ਜਾ ਸਕੇ ਜੋ ਸੁਰੱਖਿਅਤ ਹੋਵੇ ਅਤੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ, ਉਪਭੋਗਤਾ ਦੇ ਕੰਮ ਵਿੱਚ ਰੁਕਾਵਟ ਨਾ ਬਣੇ।

Windows ਉੱਤੇ Codex ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਇੱਕ ਵਧੀਆ ਅਨੁਭਵ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਕੰਮ ਕਰਦੇ ਹੋਏ, ਸਾਡਾ ਟੀਚਾ ਕੁਝ ਅਜਿਹਾ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣਾ ਸੀ ਜੋ ਉਪਯੋਗਤਾ ਨਾਲ ਸਮਝੌਤਾ ਨਾ ਕਰੇ—Codex ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਮੁੱਖ ਮਕਸਦ ਹੀ ਇਹ ਹੈ ਕਿ ਏਜੰਟ ਤੁਹਾਡੇ ਲਗਾਤਾਰ ਧਿਆਨ ਦੇ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ।

ਇਸ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਸਭ ਤੋਂ ਵੱਡੇ ਸਬਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਸੀ ਕਿ ਵਿੰਡੋਜ਼ ਨੇ ਸਾਨੂੰ ਕੋਈ ਅਜਿਹਾ ਮੁੱਢਲਾ ਸਾਧਨ ਨਹੀਂ ਦਿੱਤਾ ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ "ਸੁਰੱਖਿਅਤ ਖੁਦਮੁਖਤਿਆਰ ਕੋਡਿੰਗ ਏਜੰਟ" ਦੇ ਅਨੁਕੂਲ ਹੋਵੇ। ਅਸੀਂ ਇੱਕ ਸੁਮੇਲ ਭਰਿਆ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਕਈ ਟੂਲਸ ਅਤੇ ਧਾਰਨਾਵਾਂ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ। ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਵਿਚਾਰ ਅਸਫਲ ਰਹੇ। ਅੰਤਿਮ ਡਿਜ਼ਾਈਨ ਪੁਰਾਣੇ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਦਾ ਇੱਕ ਮਿਸ਼ਰਣ ਸੀ ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੇ ਸਮੱਸਿਆ ਦੇ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਹੱਲ ਕੀਤਾ ਸੀ।

ਦੂਜਾ ਸਬਕ ਇਹ ਸੀ ਕਿ ਇੱਕ ਕੋਡਿੰਗ ਏਜੰਟ ਲਈ ਸੁਰੱਖਿਆ, ਵਧੇਰੇ ਰਵਾਇਤੀ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਨਾਲੋਂ ਬਿਲਕੁਲ ਵੱਖਰੀ ਚੀਜ਼ ਹੈ। Codex ਨੂੰ ਅਸਲ ਡਿਵੈਲਪਰ ਵਰਕਫਲੋਜ਼ ਲਈ ਕੰਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇੰਜੀਨੀਅਰਿੰਗ ਦਾ ਕੰਮ ਏਜੰਟ-ਅਧਾਰਿਤ ਵਰਕਲੋਡਸ ਦੀ ਅਨੁਕੂਲਤਾ ਅਤੇ ਅਸਲ ਨਿਯਮਾਂ ਦੇ ਲਾਗੂਕਰਨ ਦੇ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਉਣ ਬਾਰੇ ਸੀ। ਉਸ ਖਿੱਚੋਤਾਣ ਨੇ ਅੰਤਿਮ ਡਿਜ਼ਾਈਨ ਦੇ ਫੈਸਲਿਆਂ ਨੂੰ ਰੂਪ ਦਿੱਤਾ।

Codex ਸੈਂਡਬੌਕਸ ਨੂੰ ਕਾਰਜਸ਼ੀਲ ਦੇਖਣ ਲਈ ਉਤਸੁਕ ਹੋ? ਇਸਨੂੰ ਅਜ਼ਮਾਓ⁠।