Πώς η OpenAI έφτιαξε ένα sandbox Codex σε Windows χωρίς εγγενές primitive του OS

Το κενό που ξεκίνησε από ένα χαρακτηριστικό που έλειπε από το OS

Όταν ο David Wiesen εντάχθηκε στην ομάδα μηχανικών του Codex τον Σεπτέμβριο του 2025, ο πράκτορας κώδικα δεν διέθετε καθόλου sandbox σε Windows. Αυτό άφηνε τους χρήστες Windows με δύο κακές επιλογές: να εγκρίνουν σχεδόν κάθε εντολή που ήθελε να εκτελέσει ο πράκτορας, συμπεριλαμβανομένων των αναγνώσεων, ή να ενεργοποιήσουν τη λειτουργία Full Access και να αφήσουν το Codex να εκτελεί οτιδήποτε χωρίς επίβλεψη.

Ο λόγος ήταν απλός αλλά καθοριστικός. Η προεπιλεγμένη λειτουργία του Codex — ανάγνωση σχεδόν παντού, εγγραφή μόνο εντός του χώρου εργασίας, καθόλου πρόσβαση στο διαδίκτυο εκτός αν ζητηθεί — εξαρτάται από την επιβολή αυτών των περιορισμών από το λειτουργικό σύστημα. Το macOS διαθέτει το Seatbelt· το Linux διαθέτει seccomp και bubblewrap. Τα Windows δεν προσφέρουν τίποτα αντίστοιχο εξ ορισμού.

Έτσι, το έργο της ομάδας δεν ήταν να διαμορφώσει ένα υπάρχον sandbox, αλλά να κατασκευάσει ένα από άσχετα δομικά στοιχεία των Windows. Αυτή η προσέγγιση εξηγεί γιατί το τελικό σύστημα είναι τόσο περίπλοκο.

Τρεις έτοιμες επιλογές των Windows, τρία αδιέξοδα

Η ομάδα αξιολόγησε το AppContainer, το Windows Sandbox και την επισήμανση Mandatory Integrity Control, και τα απέρριψε όλα για συγκεκριμένους, διαφορετικού τύπου λόγους.

Το AppContainer προσφέρει ένα πραγματικό όριο σε επίπεδο OS, αλλά έχει σχεδιαστεί για εφαρμογές που δηλώνουν εκ των προτέρων τις δυνατότητές τους — λάθος μοντέλο για έναν πράκτορα που χειρίζεται shells, Git, Python, διαχειριστές πακέτων και όποια δυαδικά αρχεία αποφασίσει ότι χρειάζεται. Το Windows Sandbox είναι ένα ισχυρότερο κουτί, μια αναλώσιμη εικονική μηχανή, αλλά το Codex πρέπει να ενεργεί στο πραγματικό checkout και τα εργαλεία του χρήστη, όχι σε μια αναλώσιμη επιφάνεια εργασίας· επιπλέον, δεν είναι διαθέσιμο στις εκδόσεις Windows Home, κάτι που το αποκλείει σε επίπεδο προϊόντος.

Η επισήμανση MIC integrity φαινόταν κομψή λύση — εκτέλεση του Codex σε χαμηλό επίπεδο ακεραιότητας, επανασήμανση των εγγράψιμων ριζών — αλλά το να σημαδέψεις έναν χώρο εργασίας ως χαμηλής ακεραιότητας σημαίνει ότι κάθε διαδικασία χαμηλής ακεραιότητας στο host μπορεί να γράψει εκεί, μετατρέποντας το πραγματικό checkout του προγραμματιστή σε έναν κοινό αποδέκτη σε επίπεδο συστήματος. Η αλλαγή σημασιολογίας ήταν υπερβολικά ευρεία για να δικαιολογηθεί.

Το πρωτότυπο χωρίς αυξημένα δικαιώματα και το ένα πράγμα που δεν μπορούσε να κάνει

Ο πρώτος σχεδιασμός που λειτούργησε αποφεύγει να ζητά από τους χρήστες δικαιώματα διαχειριστή. Βασίστηκε σε δύο primitives των Windows: συνθετικά αναγνωριστικά ασφαλείας (SIDs) και tokens με περιορισμούς εγγραφής. Ένα συνθετικό SID με όνομα sandbox-write αποκτούσε δικαιώματα εγγραφής, εκτέλεσης και διαγραφής στον κατάλογο εργασίας και σε όσες writable_roots είχαν οριστεί, ενώ του απαγορευόταν ρητά η εγγραφή σε ευαίσθητες διαδρομές όπως .git, .codex και .agents. Οι εντολές εκτελούνταν με ένα token περιορισμένης εγγραφής, στη λίστα περιορισμένων SIDs του οποίου περιλαμβάνονταν το Everyone, το SID της συνεδρίας και το sandbox-write.

Οι εγγραφές αρχείων λύθηκαν καθαρά. Η πρόσβαση στο δίκτυο όχι. Χωρίς δικαιώματα διαχειριστή, το Windows Firewall δεν ήταν επιλογή, οπότε η ομάδα μπόρεσε μόνο να ορίσει παρακάμψεις μεταβλητών περιβάλλοντος — κατευθύνοντας τους proxies σε ένα ανενεργό endpoint (HTTPS_PROXY=http://127.0.0.1:9), εξαναγκάζοντας το GIT_SSH_COMMAND να επιστρέφει κωδικό εξόδου 1, και προσθέτοντας έναν κατάλογο denybin στην αρχή του PATH.

Ο συγγραφέας είναι ξεκάθαρος ως προς τα όρια αυτής της προσέγγισης.

Αυτό συγκράτησε πολλή από τη συνηθισμένη κίνηση δικτύου που προκαλείται από εργαλεία, αλλά παρέμενε απλώς συμβουλευτικό μέτρο. Μια διαδικασία θα μπορούσε να αγνοήσει το περιβάλλον, να παρακάμψει το PATH ή απλά να ανοίξει sockets απευθείας — υπερβολικά επικίνδυνο.Montana Labs

Το κρίσιμο σημείο είναι ότι ακόμη και δυαδικά αρχεία που συμπεριφέρονται σωστά αλλά υλοποιούν τη δική τους στοίβα δικτύωσης θα το παρέκαμπταν. Αυτή η αδυναμία, και όχι το κόστος ρύθμισης των ACL ή η δυσκολία αλλαγής σημασιολογίας, ήταν αυτό που οδήγησε την ομάδα να εγκαταλείψει τον περιορισμό της μη ανύψωσης δικαιωμάτων.

Γιατί η πραγματική επιβολή δικτύου απαίτησε τέσσερα δυαδικά αρχεία και δύο πλασματικούς χρήστες

Το Windows Firewall μπορούσε να αποκλείσει την εξερχόμενη κίνηση, αλλά μόνο αν οι διαδικασίες στο sandbox εκτελούνταν ως διακριτός φορέας (principal). Οι κανόνες firewall δεν μπορούν να ταιριάξουν με το συνθετικό SID ενός περιορισμένου token, δεν μπορούν να διακρίνουν μια sandboxed κλήση του python.exe από κάποια άλλη, και ο αποκλεισμός μιας θύρας όπως η 443 ήταν εντελώς λανθασμένη πολιτική — ο στόχος ήταν να αποκλειστεί η αυθαίρετη εξερχόμενη πρόσβαση για ένα συγκεκριμένο δέντρο διαδικασιών.

Η λύση ήταν η δημιουργία δύο τοπικών χρηστών, του CodexSandboxOffline (στον οποίο απευθύνονταν οι κανόνες firewall) και του CodexSandboxOnline (που δεν στοχεύεται), με διαπιστευτήρια αποθηκευμένα και κρυπτογραφημένα μέσω DPAPI, όπου οι χρήστες του sandbox δεν μπορούν να τα διαβάσουν. Επειδή αυτοί οι χρήστες δεν είναι ο πραγματικός χρήστης των Windows, χάνουν την πρόσβαση ανάγνωσης σε καταλόγους που συνήθως μοιράζονται με τους Authenticated Users, οπότε το βήμα ρύθμισης παραχωρεί επίσης ACLs ανάγνωσης σε διαδρομές όπως το προφίλ χρήστη, το C:\Windows και το Program Files — εκτελείται ασύγχρονα επειδή είναι αργό.

Η εκκίνηση εντολών ως άλλος χρήστης προσέκρουσε σε ένα εμπόδιο δικαιωμάτων στο CreateProcessAsUserW, το οποίο δεν μπορούσε να εκκινήσει με αξιοπιστία μια θυγατρική διαδικασία με περιορισμένο token από την πλευρά του πραγματικού χρήστη. Η λύση ήταν η εισαγωγή του codex-command-runner.exe: το codex.exe εκκινεί τον runner ως χρήστη sandbox μέσω CreateProcessWithLogonW, και ο runner — ήδη στην πλευρά του χρήστη sandbox — δημιουργεί το περιορισμένο token και εκκινεί την πραγματική θυγατρική διαδικασία. Μαζί με ένα ειδικό δυαδικό αρχείο ρύθμισης με αυξημένα δικαιώματα, αυτό δίνει τέσσερα επίπεδα: το codex.exe, το δυαδικό αρχείο ρύθμισης, τον command runner και τη θυγατρική διαδικασία.

Η συνέπεια: η ισοτιμία πλατφορμών για το Codex ήρθε με το κόστος ενός βήματος ρύθμισης με δικαιώματα διαχειριστή

Το βασικό συμπέρασμα είναι στενό και συγκεκριμένο: για να συμπεριφέρεται το Codex το ίδιο σε Windows όπως σε macOS και Linux, η OpenAI χρειάστηκε να απαιτήσει αυξημένα δικαιώματα διαχειριστή κατά τη ρύθμιση — ακριβώς τον περιορισμό που η ομάδα προσπάθησε να αποφύγει στο πρώτο πρωτότυπο. Η καταστολή της δικτυακής πρόσβασης, η οποία έπρεπε να αντέχει σε κακόβουλο κώδικα, αποδείχθηκε μη διαπραγματεύσιμη, και στα Windows αυτό σήμαινε κανόνες firewall, που σήμαινε ξεχωριστό φορέα (principal), που σήμαινε ανύψωση δικαιωμάτων.

Για ομάδες που φτιάχνουν πράκτορες που εκτελούν τοπικές εντολές, το πρακτικό δίδαγμα εδώ είναι ότι το όριο επιβολής καθορίζει την αρχιτεκτονική, όχι το αντίστροφο. Ένας βολικός σχεδιασμός χωρίς αυξημένα δικαιώματα ήταν τεχνικά εφικτός για τις εγγραφές αρχείων, αλλά κατέρρευσε στην μία απαίτηση — τον αποκλεισμό διαρροής δεδομένων — που δεν μπορούσε να είναι απλά συμβουλευτική. Όλα τα επόμενα βήματα, από τα διαπιστευτήρια αποθηκευμένα μέσω DPAPI μέχρι το δυαδικό αρχείο command-runner, υπάρχουν για να ικανοποιήσουν αυτή τη μία αυστηρή απαίτηση.

Όπως το θέτει ο Wiesen, τα Windows δεν τους έδωσαν κανένα primitive που να αντιστοιχεί σε 'ασφαλή αυτόνομο πράκτορα κώδικα', οπότε η ομάδα δημιούργησε ένα. Το αποτέλεσμα δεν είναι, ομολογουμένως, απλό, αλλά κάθε κομμάτι — το συνθετικό SID, οι δύο χρήστες, οι ασύγχρονες παραχωρήσεις ACL ανάγνωσης, η διαχωρισμένη διαδικασία εκκίνησης — προκύπτει από μια συγκεκριμένη αποτυχία μιας απλούστερης προσέγγισης.