Windows’ta Codex’i etkinleştirmek için güvenli ve etkili bir sandbox oluşturulması

Eylül 2025'te Codex mühendislik ekibine katıldığımda, Windows için Codex'in bir sandbox uygulaması yoktu. Bu da Windows kullanıcılarının, OpenAI'ın kodlama ajanlarını kullanırken ideal olmayan iki seçenek arasında kalması anlamına geliyordu:

1. Birinci seçenek, kodlama ajanının çalıştırmak istediği neredeyse her komutu (okuma işlemleri dahil) tek tek onaylamaktı. Bu hem verimsiz hem de uğraştırıcıydı. Oysa Codex kullanmanın en büyük faydalarından biri, tüm bu zahmetli işleri sizin yapmak zorunda kalmamanızdır.
2. İkinci seçenek ise Tam Erişim modunu etkinleştirmekti. Bu mod, Codex'in tüm komutları onay veya kısıtlama olmadan çalıştırmasına izin verir. Sürtünmeyi azaltır, ancak denetimden ödün verilmesine yol açar.

Kodlama ajanımız Codex⁠, geliştiricilerin dizüstü bilgisayarlarında çalışır. Bu; CLI, IDE uzantısı veya masaüstü uygulaması üzerinden olabilir. Codex, klavye başındaki insan ve çıkarımı bulutta yürüten model arasındaki konuşmayı yönetir.

Codex varsayılan olarak gerçek bir kullanıcının izinleriyle çalışır. Bu da kullanıcının yapabildiği her şeyi yapabileceği anlamına gelir. Bu güçlü bir özelliktir, ancak potansiyel olarak risklidir. Kodlama modeli, test çalıştırmaktan bir dosyayı okumaya veya düzenlemeye, Git dalı oluşturmaya kadar yerel olarak komutlar çalıştırması için donanıma talimat verebilir. Bu nedenle Codex'in varsayılan modu, etkililik ve güvenlik arasında doğru dengeyi bulmaya çalışır. Bu modda Codex, siz özellikle istemediğiniz sürece internet erişimi olmadan, neredeyse her yerden dosya okuyabilir ve çalışma alanınızda, yani Codex'i çalıştırdığınız dizinde, dosya yazabilir. Codex'in otomatik olarak dosya değiştirme ve ağa erişme sınırlarını güvenli şekilde koruyabilmesi için, bu kısıtları gerçekten uygulayan bir sandbox ortamına ihtiyaç vardır.

Sandbox, kısıtlı bir yürütme ortamıdır. Bir geliştirici Codex'i kullandığında, bilgisayarının işletim sistemi bir komutu daha düşük izinlerle başlatır ve bu kısıtlamalar işlem ağacı boyunca alt işlemlere aktarılır. Her Codex komutu en baştan sandbox içinde çalıştırılır. Bu komuttan türeyen her alt işlem de aynı sınırlar içinde kalır.

Codex'in etkili bir sandbox uygulayabilmesi için, bilgisayarın işletim sistemi tarafından zorunlu kılınan izolasyon özelliklerine ihtiyaç vardır. Bazı işletim sistemleri bunu iyi şekilde yapan yardımcı araçlar sağlar. Örneğin, macOS'ta Seatbelt, Linux'ta ise seccomp veya bubblewrap kullanılabilir. Ancak Windows şu anda bu tür bir kabiliyeti hazır olarak sunmaz.

Codex'i Windows'ta da diğer platformlarda olduğu kadar güvenli ve sorunsuz kullanılabilir hale getirmek için kendi sandbox'ımızı uygulamamız gerekiyordu.

Windows, izolasyon için bazı araçlar ve temel yapı taşları sunar. Bunların hiçbiri gereksinimlerimizi tam olarak karşılamasa da birkaç olası çözümü inceledik: AppContainer, Windows Sandbox ve Mandatory Integrity Control etiketlemesi.

AppContainer

• Nedir?: AppContainer, Windows'un yerel sandbox mekanizmasıdır. Neye erişmesi gerektiğini en baştan tam olarak bilen uygulamalar için geliştirilmiş, yetenek tabanlı bir izolasyon modelidir.
• Neden?: En iyi çabalı kısıtlamalar yerine gerçek bir işletim sistemi sınırı sunması nedeniyle caziptir.
• Neden değil?: Codex, kapsamı dar şekilde tanımlanmış tek bir uygulama değildir. Shell'ler, Git, Python, paket yöneticileri, derleme araçları ve ajanın ihtiyaç duyduğuna karar verdiği diğer ikili dosyalarla açık uçlu geliştirici iş akışlarını yürütür. Pratikte bu durum, AppContainer'ı bu sorun için uygun olmayan bir kalıba soktu. Güçlü bir izolasyon sağlıyordu. Ancak "bir ajanın geliştirici gibi çalışmasına izin verme" ihtiyacına kıyasla çok daha dar bir iş yükü sınıfı için tasarlanmıştı.

Windows Sandbox

• Nedir?: Windows Sandbox, Microsoft'un tek kullanımlık ve hafif sanal makine çözümüdür. Güçlü bir izolasyon sınırına sahip yeni bir Windows masaüstü sunar. Bu ortamda yaptığınız her şey, oturum sona erdiğinde silinir.
• Neden?: Bariz nedenlerle ilginç bir seçenekti. AppContainer'a kıyasla rastgele yazılımlarla çok daha uyumludur ve güvenlik açısından çok daha güçlü bir sınır sunar.
• Neden değil?: Codex'in, kurulum ve ana sistem/konuk ortam arasında köprüleme gerektirecek ayrı ve geçici bir masaüstü içinde değil; doğrudan kullanıcının gerçek kod kopyası, araçları ve ortamı üzerinde çalışması gerekir. Ayrıca temel bir ürün sorunu da vardı: Windows Sandbox, Windows Home SKU'larında mevcut değildir.

Mandatory Integrity Control (MIC) bütünlük etiketlemesi

• Nedir?: Windows'ta "bütünlük düzeyleri" adı verilen bir kavram vardır. Düşük, orta ve yüksek gibi bu düzeyler, sistemin nesnelere ve işlemlere ne kadar güvendiğini belirler. Temel kural şudur: Normal ACL izin verse bile, daha düşük bütünlük düzeyine sahip bir işlem, daha yüksek bütünlük düzeyine sahip bir nesneye yazamaz. Örneğin, düşük bütünlük düzeyine sahip bir işlem, daha az güvenilir kabul edilir. Bu nedenle Windows, ilgili nesneler buna izin verecek şekilde açıkça yeniden etiketlenmedikçe, bu işlemin normal orta bütünlük düzeyindeki nesnelere yazmasını engeller.
• Neden?: MIC kağıt üzerinde zarif görünüyordu; Codex’i düşük bütünlükte çalıştır, yazılabilir kökleri düşük bütünlük olarak yeniden etiketle ve başka her yerde yazılamamayı Windows uygulasın. Bu bize, arkasında gerçek bir işletim sistemi mekanizması olan, yönetici gerektirmeyen bir yol sunacaktı.
• Neden olmasın: ACL'ler gibi, bütünlük etiketleri de gerçek ana makine dosya sistemini değiştirir ve bu durumda anlamsal değişiklik özellikle geniş kapsamlıdır. Bir çalışma alanını düşük bütünlük düzeyinde işaretlemek yalnızca "Codex buraya yazabilir" anlamına gelmez. Bu, düşük bütünlük düzeyindeki işlemlerin genel olarak oraya yazabileceği anlamına gelir. Gerçek bir geliştirici makinesinde bu, kullanıcının gerçek kod kopyasını ana makine için düşük bütünlük düzeyine sahip işlemler için yazılabilir bir hedef haline getirir. Bu da belirli bir sandbox tasarımına dikkatle hedeflenmiş ACL'ler vermekten çok daha risklidir. Orta bütünlük düzeyindeki geliştirici araçları çalışmaya devam etse bile çalışma alanının temel güven modeli, kontrol edilmesi zor ve gerekçelendirilmesi daha da zor bir şekilde değişmiş olur.

Tüm seçeneklerin uygulanamaz olduğu sonucuna vardıktan sonra, Windows kullanıcılarına iyi bir Codex deneyimi sunmak için kendi çözümümüzü tasarlamaya başladık.

İlk çalışan prototipimiz, ihtiyaç duyduğumuz izolasyonu sağlamak için Windows kavramları ve araçlarının bir kombinasyonunu kullandı. En başından itibaren hedeflerimizden biri, bu süreci yükseltme gerektirmeden çalıştırmaktı. Başka bir deyişle, Codex'in, sandbox'ı kurmak veya çalıştırmak için kullanıcıdan yönetici ayrıcalıkları istemesine gerek kalmayacaktı. Bu da iki konuda (dosya yazma ve ağ erişimi) makul sınırları nasıl koyacağımızı çözmemiz gerektiği anlamına geliyordu.

Dosya yazmalarını hiç sınırlamasaydık güvenlik sorunu yaşardık. Fazla sınırlasaydık da sandbox kullanıcı verimliliğine zarar verir, sürekli onay isterdi. Bu sorunu çözmek için Windows'un iki önemli yapı taşına dayandık: SID’ler ve yazma kısıtlı token'lar.

SID, yani güvenlik tanımlayıcısı, Windows'un izinlerle ilişkilendirdiği kimliktir. Her kullanıcının bir SID'si vardır. Grupların SID'leri vardır. Hatta tek bir oturum açma oturumunun bile kendi SID'si bulunur. Örneğin, o anda açık bir oturumun S-1-5-5-X-Y gibi bir SID'si olabilir. Yerel yöneticiler grubuna atanmış SID ise S-1-5-32-544 olabilir.

Windows ayrıca gerçek bir kullanıcıya karşılık gelmeyen sentetik SID'ler oluşturmanıza da olanak tanır. Bu SID'ler yine de belirli dosya veya dizinleri kimin okuyabileceğini, yazabileceğini ya da çalıştırabileceğini tanımlayan ACL'lerde, yani erişim denetim listelerinde, yer alabilir. Bu da SID'leri sandbox'ımız için kullanışlı bir temel yapı taşı haline getirir: Makinedeki başka hiçbir şeyi etkilemeden, yalnızca Codex sandbox'ının kullanacağı SID'ler oluşturabiliriz.

İşlem token'ları, Windows'ta çalışan bir işlemin kimliğini ve ayrıcalıklarını tanımlayan güvenlik nesneleridir. Bir işlemin hangi eylemleri gerçekleştirebileceğini belirlerler. Yazma kısıtlı token, Windows'un yazma işlemleri için ek bir erişim denetimi yapmasını sağlayan belirli bir işlem token'ı türüdür.

Bir yazma işleminin başarılı olması için iki denetimden geçmesi gerekir:

1. Normal kullanıcı kimliğine, yani token'ın "sahibine", bu işlemi yapma izni verilmiş olmalıdır.
2. Token'ın kısıtlı SID listesindeki en az bir SID için de erişim izni verilmiş olmalıdır.

Pratikte bu denetimler, sandbox'ın dosya sisteminde tam olarak hangi konumları değiştirebileceğini tanımlamak için ACL'lerden yararlanmamızı sağladı. Böylece yazma işlemleri için ihtiyaç duyduğumuz ayrıntılı kontrol düzeyini elde ettik.

SID'ler ve yazma kısıtlı token'larla, yükseltilmemiş sandbox'ımız şu şekilde çalışıyordu:

1. Sandbox kurulumu, sandbox-write adlı sentetik bir SID oluşturuyordu.
2. sandbox-write SID'sine şu konumlar için yazma, yürütme ve silme erişimi veriliyordu:
   1. Mevcut çalışma dizini
   2. config.toml içinde yapılandırılan ek writable_roots dizinleri
3. Sandbox kurulumu, aynı SID'nin "yazılabilir dizin içindeki salt okunur" konumlara yazma erişimini açıkça reddediyordu:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex, komutları yazma kısıtlı bir token ile başlatıyordu. Bu token'ın kısıtlı SID listesinde Everyone, o anda açık olan oturumun SID'si ve sandbox-write adlı sentetik SID yer alıyordu.

Bu akış, dosya yazmalarını sınırlama sorununu etkili biçimde çözdü ve umut verici görünüyordu. Şimdi sandbox’ın ağ erişimini sınırlamak için bir çözüme ihtiyacımız vardı.

Ağ erişimini sınırlamak, sandbox’ın önemli bir parçasıdır; aksi halde kötü amaçlı kod, makineden internete veri sızdırabilirdi. Yetki yükseltme gereksiniminden kaçınmak istediğimiz için, ağ trafiğini güçlü biçimde engellemek adına sınırlı seçeneklerimiz vardı. Kullanmak istediğimiz Windows Güvenlik Duvarı gibi araçlar genellikle yönetici izinleri olmadan kurulamazdı.

Windows Güvenlik Duvarı seçenek dışı kalınca, kontrol edebileceklerimiz de sınırlı oldu. Alt ortamı, geliştiricilerin fiilen kullandığı türden ağ bağlantılı araçlar için varsayılan olarak kapalı kalacak şekilde başarısız olacak biçimde tasarlamaya çalıştık; böylece Git komutları, paket yükleyiciler vb. sandbox'ta başarısız olacak ve kullanıcının internete yönelik tüm işlemleri onaylaması gerekecekti. Amaç, belirgin kaçış yollarını devre dışı bırakmak için proxy farkındalığı olan trafiği çalışmayan bir uç noktaya yönlendiren, Git'in HTTP(S) aktarımının da aynı şekilde davranmasını sağlayan ve SSH üzerinden yapılan Git işlemlerini hemen başarısız kılan bir yapı kurmaktı. Bunun yanı sıra, küçük bir denybin dizinini PATH’in başına ekledik ve stub SSH ile SCP betikleri gerçek ikili dosyalardan önce çözümlenecek şekilde PATHEXT değerini yeniden sıraladık.

Örneğin, ağ erişimini sınırlamak için kullandığımız belirli ortam geçersiz kılmalarından bazıları şunlardır:

• 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

Bu, normal araçlar üzerinden gelen trafiğin büyük kısmını yakaladı, ancak yine de yalnızca tavsiye niteliğindeydi. Bir işlem ortam ayarlarını yok sayabilir, PATH'i atlayabilir veya doğrudan soket açabilirdi. Bu da fazla riskliydi.

Her ilginç yazılım uygulamasında olduğu gibi, ilk prototipin de güçlü ve zayıf yönleri vardı. Yalnızca birkaç standart Windows yeteneğiyle çalışıyor, dosya sistemine yazma işlemleri üzerinde net ve ayrıntılı kontrol sağlıyor ve yükseltme gerektirmeden çalışıyordu. Başka bir deyişle, kullanıcıların çok sayıda yükseltme promptunu onaylaması veya yerel makinelerinde yönetici olması gerekmiyordu. Buna rağmen bazı gerçek dezavantajları vardı ve bunlardan birkaçı, bu yaklaşımın nihai tasarımımız olmamasına yol açtı:

• Kurulum hızı: Çalışma alanı ACL'lerini uygulamak, çalışma alanı dizininin yapısına bağlı olarak maliyetli olabilir.
• Ayak izi: Geliştiricinin sistemine gerçek ACL'ler uyguladık. Ancak uygulanan ACL'lerin tamamı yalnızca sandbox tarafından kullanılan, özel olarak oluşturulmuş sentetik bir SID ile ilgili olduğu için bu ayak izi özellikle müdahaleci değildir.
• Değiştirilmesi zor semantik: Dosya tabanlı kısıtlamalar için ACL'lere dayanmak, sandbox semantiğini değiştirmenin maliyetli ve karmaşık olduğu anlamına gelir. MacOS'ta Seatbelt'i yapılandırmak için kullanılan .sbpl dosyasını nasıl oluşturduğumuzu dinamik olarak değiştirebiliyorduk. Windows sandbox'ta ise ACL'leri ayarlamak yavaş ve yoğun bir işlem gerektirebiliyordu.
• Ağ koruması zayıftı. Daha önce belirttiğimiz gibi bu yaklaşım "tavsiye" niteliğindeydi. Kendi ağ altyapısını uygulayan bazı programlar tarafından kesinlikle aşılabilirdi ve kötü niyetli kodlara dayanacak şekilde tasarlanmamıştı.

İlk üç sorun, ajan tabanlı iş akışları için yeterince esnek olan özel bir sandbox uygulamasının doğal sonuçlarıydı. Ancak ağ erişimini baskılama konusu farklıydı.

Kötü amaçlı bir ajan, ortam değişkenlerine dayalı ağ baskılamasını kolayca aşabilirdi. Üstelik iyi niyetli birçok kod veya ikili dosya da ortam proxy değişkenlerine uymadığında ya da kendi soket tabanlı ağ kodunu uyguladığında bu baskılamayı aşabiliyordu. Bu nedenle, daha iyi bir sandbox moduna yatırım yapmayı gerektirecek kadar önemli bir sorunla karşı karşıya olduğumuzu düşündük.

Daha güçlü ağ baskılaması elde etmek için Windows Güvenlik Duvarı'nı kullanmak istedik. Bu güvenlik duvarı, kullanıcılar veya programlar için dışa giden ağ trafiğini engellememize olanak tanır. Ne yazık ki, yalnızca Codex donanımı tarafından başlatılan komutlara uygulanacak işlevsel bir güvenlik duvarı kuralını birkaç nedenle etkili şekilde oluşturamadık:

• Windows, bir güvenlik duvarı kuralının kısıtlı bir token'ın birincil olmayan kimliğiyle eşleşmesine izin vermez. Bu, "kısıtlı SID listesinde sentetik SID'mizi içeren herhangi bir token" için güvenlik duvarı kuralı uygulayamadığımız anlamına geliyordu.
• Belirli bir ikili dosyayla eşleşen bir güvenlik duvarı kuralı oluşturabilsek de bu yalnızca codex.exe için ağ erişimini sınırlamamıza olanak tanırdı. Bu kural, ajanın kullanıcı adına başlattığı Git veya Python işlemleri gibi alt işlemlere uygulanmazdı.
• Diğer güvenlik duvarı eşleştirme boyutları da uygun değildi. Kullanıcı kapsamlı kurallar, yükseltilmemiş tasarımda yalnızca kısıtlı alt işlemle değil, gerçek Windows kullanıcısıyla da eşleşmeye devam ediyordu. Program yolu kuralları bu iş için yeterince ayrıntılı değildi: codex.exe'yi veya genel olarak python.exe'yi engelleyebiliyordu, ancak python.exe'nin yalnızca sandbox içinde başlatılan belirli bir örneğini hedefleyemiyordu. Port veya adres temelli kurallar da bu amaç için tamamen yanlış bir politikaydı. Örneğin, 443 numaralı portu engellemek istemiyorduk. İstediğimiz, yalnızca bu belirli kısıtlı işlem ağacı için rastgele dışa giden erişimi engellemekti.

Güvenlik duvarı kuralını özellikle sandbox içindeki komutlarımıza uygulamak için bu komutları "gerçek" kullanıcı olarak değil, ayrı bir birincil kimlik olarak çalıştırmamız gerekiyordu. Bu yaklaşım bizi yeni bir yola, yani "yükseltme yok" kısıtını gevşettiğimiz bir tasarıma götürdü.

Sandbox'ın bir sonraki yinelemesi, yani mevcut uygulamamız, kurulum sırasında yükseltilmiş yönetici izinleri gerektirir. Bu nedenle buna "yükseltilmiş sandbox" diyorum. Codex'in sistemde bir komut başlattığı noktada, yükseltilmiş sandbox yükseltilmemiş versiyona benzer görünür. Alt işlemleri halen kısıtlı bir token altında çalıştırır. Bu token, aynı kısıtlı SID listesine sahip write_restricted token'a benzer: [Everyone, Logon, Synthetic]. Ancak bu token'ın birincil kimliği artık gerçek Windows kullanıcısı değil, Codex'in kendisi tarafından oluşturulan iki yerel kullanıcıdan biridir:

• CodexSandboxOffline (güvenlik duvarı kurallarının hedeflediği kullanıcı)
• CodexSandboxOnline (güvenlik duvarı kurallarının hedeflemediği kullanıcı)

Görünüşte küçük olan bu ayrıntının aslında sandbox, onu kimin kullanabildiği ve kurulum ile çalışma zamanı yürütmesinin karmaşıklığı açısından büyük sonuçları var.

Görsel olarak yükseltilmemiş prototipe benziyor; fark olarak güvenlik duvarı kuralları ve komutları gerçekten çalıştıran özel bir Windows kullanıcısı eklenmiş durumda. (Ancak bu yeni kavramların devreye girmesi, sandbox komutları çalıştırmaya ve korumaya başlamadan önce daha fazla kurulum işi yapılması gerektiği anlamına geliyor.)

Yükseltilmemiş sandbox tasarımının basit ama görece küçük bir kurulum adımı vardı:

• Gerekirse sentetik bir SID oluşturma
• Sandbox-write sentetik SID'si için ACL'leri uygulama

Ancak yükseltilmiş sandbox'ın yapması gereken daha fazla iş vardır.

• Henüz oluşturulmadıysa sentetik bir SID oluşturma
• Henüz oluşturulmadıysa online ve offline sandbox kullanıcıları oluşturma
• Yeni oluşturulan kullanıcıların kimlik bilgilerini yerel olarak saklama ve sandbox kullanıcılarının gerçekte okuyamayacağı bir yerde Windows Data Protection API (DPAPI) kullanarak şifreleme
• CodexSandboxOffline kullanıcısı için tüm dışa giden ağ erişimini engelleyen güvenlik duvarı kuralları oluşturma veya zaten varsa doğru olduklarını onaylama

Kurulum aşamasında bir ayrıntı daha vardı. Codex sandbox'ın, gerçek Windows kullanıcısıyla aynı düzeyde okuma erişimine sahip olması beklenir. Yükseltilmemiş sandbox'ta, kısıtlı token'ın ana SID'si Windows kullanıcısına ait olduğu için bu erişim sağlanabiliyordu. Ancak ana kimlik yeni bir CodexSandbox kullanıcısına ait olduğunda bu erişim kendiliğinden gelmez. Windows'taki birçok ilgili dizin, "Authenticated Users" grubuna okuma/yürütme izni verir. Bunun dikkat çekici örneklerinden biri, kullanıcının profil dizinidir. Varsayılan olarak Windows kullanıcıları, diğer Windows kullanıcılarının profil dizinlerini okuyamaz. Bu nedenle birçok senaryoda basit dosya okuma işlemleri bile başarısız olurdu.

Bunu çözmek için sandbox kurulum sürecine bir katman daha ekledik. Bu katman, gerekli ACL'lerin henüz bulunmadığı konumlarda sandbox kullanıcılarına okuma izni vermemizi sağladı. Örneğin, yaygın kullanılan bazı Windows dizinleri için:

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

Bu dizin listesi en iyi çabaya dayalı olduğu ve her biri için ACL yüklemek oldukça maliyetli olabileceği için, bu mantığı eşzamansız çalıştırıyoruz. Böylece kullanıcı açısından engelleyici olan sandbox kurulum adımının bu işlemlerin tamamlanmasını beklemesi gerekmiyor.

Kurulum mantığını ayrı bir ikili dosyada topladık. Bunun nedenlerinden biri, UAC sınırını yalnızca gerçekten gerektiğinde geçmekti. Ancak daha temel neden mimariydi: Sandbox kurulumu, codex.exe'den temelde farklı bir iş yapar. Sandbox kurulum mantığını özel bir ikili dosyada tutmak birkaç avantaj sağladı: codex.exe normal, yükseltilmemiş bir donanım olarak kalabildi; Windows'a özgü kurulum mekanizması diğer platformlarda codex.exe'yi gereksiz yere büyütmedi; daha uzun süren kurulum işleri, ana işlemin yaşam süresinden ayrıldı ve sandbox'ın ihtiyaç duyduğu farklı kurulum yollarını yönetmek için tek bir merkezi yerimiz oldu.

Windows'ta kullanıcı ve token oturum açma sınırlarının çalışma biçimi nedeniyle, yükseltilmemiş sandbox'ta yaptığımız gibi kısıtlı bir token oluşturup bunun altında işlem başlatmaya devam edemedik. Komutları gerçekten farklı bir Windows kullanıcısı olarak başlatmak için ilk fikrimiz şu akışı kullanmaktı:

• codex.exe gerçek Windows kullanıcısı olarak çalışır. Ardından Codex sırasıyla şunları yapar:
  • Sandbox kullanıcısı için LogonUserW(...) çağrısı yapar.
  • Bu sandbox kullanıcısı token'ı üzerinde CreateRestrictedToken(...) çağrısı yapar.
  • Bu kısıtlı sandbox kullanıcısı token'ı ile son alt işlemi başlatmak için CreateProcessAsUserW(...) çağrısı yapar.

Pratikte bu akış, CreateProcessAsUserW(...) aşamasındaki ayrıcalık sınırı nedeniyle çalışmadı. Yani codex.exe, sandbox kullanıcısı için kısıtlı bir token oluşturabiliyordu; ancak halen gerçek kullanıcı tarafındayken bu token ile güvenilir biçimde bir alt işlem başlatamıyordu. Halihazırda sandbox kullanıcısı olarak çalışan bir işleme ihtiyacımız vardı. Böylece kısıtlama adımı ve son işlem başlatma adımı, gerçek kullanıcı tarafında değil, sınırın sandbox kullanıcısı tarafında gerçekleşecekti.

Bu ihtiyaç, yalnızca kısıtlı bir token oluşturup istenen komutu başlatmaktan sorumlu yeni bir ikili dosyaya (codex-command-runner.exe) neden oldu. Tüm akışı tek başına codex.exe'ye yaptırmak yerine, yani gerçek kullanıcı → sandbox kullanıcısı → kısıtlı token → alt işlem zincirini tek süreçte yürütmek yerine, akışı ikiye böldük:

1. Bölüm

• codex.exe, henüz kısıtlı bir token kullanmadan codex-command-runner.exe'yi sandbox kullanıcısı olarak başlatmak için CreateProcessWithLogonW(...) çağrısı yapar.

2. Bölüm

• Çalıştırıcı içinde OpenProcessToken(GetCurrentProcess(), ...), çalıştırıcının kendi token'ını açar. Bu token zaten sandbox kullanıcısına aittir.
• Çalıştırıcı, sandbox oturum açma SID'sini almak için GetTokenInformation(...) çağrısı yapar. Ardından son kısıtlı token'ı oluşturmak için CreateRestrictedToken(...) çağrısı yapar.
• Yine çalıştırıcı içinde, gerçek alt işlemi başlatmak için bu kısıtlı token ile CreateProcessAsUserW(...) çağrısı yapar.

Albert Einstein şöyle demiştir: "Her şey olabildiğince basit yapılmalı, ama daha basit değil." Bu yaklaşımı izlediğimizde tasarımımız, her sorunu yeterli düzeyde çözdü. Nihai mimari, daha önce ele aldığımız dört katmandan oluşur:

• codex.exe'nin kendisi
• Yetki yükseltmesi gerektiren kurulumla ilgili tüm işleri yapan codex-windows-sandbox-setup.exe
• Kısıtlı token komutlarını çalıştıran codex-command-runner.exe
• Alt işlem

Bu projeye ilk başladığımda, işin nereye varacağına dair güçlü bir fikrim yoktu. İlk yaklaşımım, sandbox yeteneğini Codex ile işletim sistemi arasındaki sınırda araçlarla gözlemleyerek başlamak oldu. Bu yaklaşım, Codex sandbox’ının MacOs ve Linux’ta uygulanma biçimiyle yakından örtüşüyordu.

Windows'un sunduğu araçları daha iyi tanıdıkça ve güvenlik ile kullanım kolaylığı arasında denge kuran onlarca karar verdikçe, sistem de birden fazla ikili dosyayı, özel kullanıcıları, güvenlik duvarı kurallarını, yükseltilmiş bir kurulum adımını, senkronize olmayan işlemleri ve daha fazlasını içeren bugünkü yapısına kavuştu.

Bu özellikle basit bir sistem değil. Ancak hem güvenli hem de kullanıcıyı mümkün olduğunca az zorlayan bir sandbox oluşturmak için her karmaşıklık unsuru belirli bir ihtiyaçtan doğdu.

Windows'taki Codex kullanıcılarına iyi bir deneyim sunmaya çalışırken hedefimiz, kullanışlılıktan ödün vermeyen güvenli bir sistem geliştirmekti. Sonuçta Codex'i kullanmanın asıl amacı, ajanların sürekli dikkatinizi gerektirmeden iş yapabilmesidir.

Bu projeden çıkardığımız en büyük derslerden biri, Windows'un bize doğrudan "güvenli otonom kodlama ajanı" kavramına karşılık gelen tek bir temel yapı taşı sunmamasıydı. Tutarlı bir sistem oluşturmak için birkaç aracı ve kavramı bir araya getirmemiz gerekti. İlk fikirlerimizin bazıları çıkmaz sokaktı. Nihai tasarım ise her biri sorunun bir bölümünü çözen önceki prototiplerin hibrit bir birleşiminden oluştu.

Çıkardığımız bir diğer ders de, kodlama ajanı güvenliğinin klasik uygulama güvenliğinden farklı bir mesele olduğuydu. Codex'in gerçek geliştirici iş akışlarında çalışması gerekir. Mühendislik çalışması, ajan iş yükleriyle uyumluluğu gerçek yaptırımla dengelemek üzerine kuruldu. Bu gerilim, nihai tasarımdaki ödünleri şekillendirdi.

Codex sandbox'ı çalışırken görmek ister misiniz? Deneyin⁠.