การสร้างแซนด์บ็อกซ์ที่มีความปลอดภัยและมีประสิทธิภาพเพื่อใช้งาน Codex บน Windows

เมื่อผมเข้าร่วมทีมวิศวกร Codex ในเดือนกันยายน 2568 Codex สำหรับ Windows ยังไม่มีการใช้งานแซนด์บ็อกซ์ ทำให้ผู้ใช้ Windows ถูกบังคับให้ต้องเลือกระหว่างทางเลือกที่ไม่ดีนัก 2 ทาง เมื่อใช้เอเจนต์เขียนโค้ดของ OpenAI:

1. การต้องมานั่งกดยอมรับเกือบทุกคำสั่งที่ AI จะรัน แม้แต่การแค่อ่านไฟล์เฉยๆ ก็ตาม เป็นเรื่องที่เสียเวลาและน่าหงุดหงิด หัวใจสำคัญของ Codex คือการช่วยให้เราไม่ต้องมานั่งเหนื่อยกับงานจุกจิกพวกนี้เอง
2. การเปิดใช้งานโหมดเข้าถึงเต็มรูปแบบ คือการอนุญาตให้ Codex รันคำสั่งทั้งหมดได้โดยไม่ต้องผ่านการอนุมัติหรือมีข้อจำกัดใดๆ ซึ่งช่วยลดความยุ่งยากในการทำงาน แต่ต้องแลกมาด้วยการขาดการกำกับดูแลที่เหมาะสม

Codex⁠ ซึ่งเป็นเอเจนต์ช่วยเขียนโค้ดของเราทำงานได้โดยตรงบนเครื่องของเหล่านักพัฒนาครับ ทั้งผ่าน CLI ส่วนขยาย IDE หรือแอปบนเดสก์ท็อป เอเจนต์จะคอยประสานงานการสื่อสารระหว่างตัวผู้ใช้และโมเดลที่อยู่บนคลาวด์เพื่อใช้ในการประมวลผลคำสั่งต่างๆ

ค่าเริ่มต้นของ Codex คือการทำงานด้วยสิทธิ์เดียวกับผู้ใช้จริง นั่นแปลว่ามันทำทุกอย่างที่ผู้ใช้ทำได้ ซึ่งแน่นอนว่ามีทั้งข้อดีและข้อเสี่ยง เพราะ AI อาจสั่งรันคำสั่งในเครื่องได้สารพัด ตั้งแต่ทดสอบโค้ด การอ่านหรือแก้ไขไฟล์ หรือการสร้าง Git Branch ดังนั้นโหมดพื้นฐานของ Codex จึงถูกออกแบบมาให้สมดุลที่สุดระหว่างความเก่งและความปลอดภัย โดยโหมดนี้ทำให้ Codex อ่านไฟล์ได้เกือบทุกจุด แต่จะเขียนไฟล์ได้แค่ในเวิร์กสเปซที่รันอยู่เท่านั้น หรือแค่ในโฟลเดอร์ที่ใช้รัน Codex โดยจะยังไม่เปิดการเข้าถึงอินเทอร์เน็ต เว้นแต่ผู้ใช้จะกำหนดให้ใช้งาน เพื่อให้ข้อจำกัดเรื่องการเขียนไฟล์และการเข้าถึงเครือข่ายถูกควบคุมให้อยู่ในระดับที่ปลอดภัยโดยอัตโนมัติ Codex จึงต้องอาศัยสภาพแวดล้อมแซนด์บ็อกซ์ที่สามารถบังคับใช้ข้อกำหนดเหล่านี้ได้จริง

แซนด์บ็อกซ์ คือสภาพแวดล้อมที่จำกัดการทำงาน เมื่อนักพัฒนาเริ่มใช้ Codex ระบบปฏิบัติการจะสั่งให้คำสั่งทำงานภายใต้การจำกัดสิทธิ์ที่มีความปลอดภัยสูง ซึ่งกลไกการควบคุมนี้จะครอบคลุมไปถึงกระบวนการทำงานลำดับถัดไปทั้งหมด ส่งผลให้ทุกการดำเนินงานของ Codex เริ่มต้นและสิ้นสุดอยู่ภายใต้ขอบเขตความปลอดภัยที่เข้มงวดเสมอ

Codex จำเป็นต้องใช้ฟีเจอร์การแยกส่วนที่บังคับใช้โดยระบบปฏิบัติการของคอมพิวเตอร์เพื่อสร้างแซนด์บ็อกซ์ที่มีประสิทธิภาพ ระบบปฏิบัติการบางระบบมีเครื่องมือที่รองรับส่วนนี้ได้ดี (เช่น Seatbelt ใน MacOS หรือ seccomp และ bubblewrap ใน Linux) อย่างไรก็ตาม ในปัจจุบัน Windows ยังไม่มีขีดความสามารถประเภทนี้มาให้พร้อมใช้งานทันที

เพื่อทำให้ Codex บน Windows ปลอดภัยและน่าใช้งานเหมือนกับในระบบอื่นๆ เราเลยต้องลงมือสร้างระบบแซนด์บ็อกซ์ขึ้นมาใช้เอง

Windows มีเครื่องมือและองค์ประกอบพื้นฐานสำหรับการแยกส่วนการทำงาน แม้ว่าจะไม่มีตัวเลือกใดที่ตอบโจทย์ความต้องการของเราได้ครบ แต่เราก็ได้พิจารณาแนวทางอื่นๆ ไม่ว่าจะเป็น AppContainer, Windows Sandbox และการใช้ป้ายระบุระดับความน่าเชื่อถือของระบบควบคุมความปลอดภัย (Mandatory Integrity Control)

AppContainer

• AppContainer คืออะไร: แซนด์บ็อกซ์มาตรฐานของ Windows ซึ่งเป็นโมเดลการแยกส่วนการทำงานตามความจำเป็นของแอป โดยออกแบบมาสำหรับแอปพลิเคชันที่รู้ล่วงหน้าอยู่แล้วว่าต้องเข้าถึงไฟล์หรือระบบส่วนไหนบ้าง
• ทำไมถึงน่าสนใจ: แนวทางนี้มีความน่าสนใจเนื่องจากเป็นการสร้างขอบเขตการทำงานในระดับระบบปฏิบัติการที่แท้จริง ไม่ใช่แค่การพยายามจำกัดสิทธิ์การเข้าถึงแบบเท่าที่เครื่องมือจะอำนวย
• ทำไมถึงไม่ตอบโจทย์: Codex ไม่ใช่แอปที่มีขอบเขตงานตายตัว มันต้องรองรับเวิร์กโฟลว์ของนักพัฒนาที่ไม่มีรูปแบบตายตัว ทั้งเชลล์, Git, Python, โปรแกรมจัดการแพ็กเกจ, เครื่องมือสำหรับบิลด์ซอฟต์แวร์ รวมถึงไฟล์ไบนารีอื่น ๆ ที่เอเจนต์พิจารณาว่าจำเป็นต้องใช้ ในทางปฏิบัติ AppContainer จึงมีรูปแบบที่ไม่เหมาะสมกับโจทย์นี้ แม้จะมีระบบแยกส่วนการทำงานที่แข็งแกร่ง แต่ก็เหมาะกับงานที่จำกัดกว่าความต้องการในระดับที่ต้อง “ยอมให้เอเจนต์ทำงานได้เหมือนนักพัฒนา”

Windows Sandbox

• คืออะไร: Windows Sandbox คือ VM ที่ประหยัดทรัพยากรและไม่เก็บข้อมูลค้างไว้ คุณจะได้ใช้หน้าจอ Windows ที่สะอาดใหม่เอี่ยมพร้อมระบบรักษาความปลอดภัยที่แน่นหนา โดยข้อมูลทุกอย่างที่คุณทำไว้จะหายไปทันทีเมื่อปิดการใช้งาน
• ทำไมถึงน่าสนใจ: ทางเลือกนี้น่าสนใจด้วยเหตุผลที่ชัดเจน เพราะมันรองรับซอฟต์แวร์ได้หลากหลายกว่า AppContaine มาก และในแง่ของความปลอดภัยถือเป็นระบบการแยกส่วนที่ดีกว่าอย่างเห็นได้ชัด
• ทำไมถึงไม่ตอบโจทย์: Codex จำเป็นต้องปฏิบัติงานโดยตรงบนไฟล์งานที่ผู้ใช้ดึงออกมาจากระบบจริง รวมถึงเครื่องมือและสภาพแวดล้อมจริงของผู้ใช้งาน มากกว่าที่จะทำงานภายในหน้าจอเดสก์ท็อปแบบใช้แล้วทิ้งที่แยกต่างหาก ซึ่งต้องมีการตั้งค่าและเชื่อมโยงระหว่างเครื่องโฮสต์กับเครื่องเสมือน นอกจากนี้ยังมีปัญหาพื้นฐานด้านผลิตภัณฑ์คือ Windows Sandbox ไม่สามารถใช้งานได้ใน Windows รุ่น Home

การใช้ป้ายระบุระดับความน่าเชื่อถือของระบบควบคุมความปลอดภัย MIC

• คืออะไร: ใน Windows จะมีสิ่งที่เรียกว่า “ระดับความน่าเชื่อถือ” เช่น ระดับต่ำ กลาง และสูง ซึ่งใช้กำหนดว่าระบบมีความเชื่อมั่นต่อวัตถุและกระบวนการต่างๆ มากน้อยเพียงใด กฎพื้นฐานคือกระบวนการที่มีระดับความน่าเชื่อถือต่ำกว่าจะไม่สามารถเขียนข้อมูลลงในวัตถุที่มีระดับความน่าเชื่อถือสูงกว่าได้ แม้ว่ารายการควบคุมการเข้าถึงตามปกติจะอนุญาตก็ตาม ตัวอย่างเช่น กระบวนการระดับต่ำจะถูกปฏิบัติในฐานะส่วนที่ไม่ได้รับความไว้วางใจ Windows จึงปิดกั้นไม่ให้เขียนข้อมูลลงในวัตถุระดับกลางทั่วไป เว้นแต่ว่าวัตถุเหล่านั้นจะได้รับการเปลี่ยนป้ายกำกับใหม่เพื่ออนุญาตโดยเฉพาะ
• ทำไมถึงน่าสนใจ: แนวคิดเรื่อง MIC นั้นดูดีมากในทางทฤษฎี เนื่องจากเป็นการรัน Codex ด้วยระดับความน่าเชื่อถือต่ำ แล้วปล่อยให้ Windows บังคับใช้มาตรการห้ามเขียนข้อมูลในส่วนอื่นๆ ทั้งหมด วิธีนี้จะช่วยให้เรามีแนวทางปฏิบัติงานแบบที่ไม่ต้องใช้สิทธิ์ผู้ดูแลระบบ โดยมีกลไกของระบบปฏิบัติการจริงรองรับอยู่เบื้องหลัง
• ทำไมถึงไม่ตอบโจทย์: เช่นเดียวกับ ACL การติดป้ายกำกับระดับความน่าเชื่อถือจะส่งผลกระทบต่อระบบไฟล์จริงของเครื่องโฮสต์ และในกรณีนี้การเปลี่ยนแปลงเชิงความหมายจะส่งผลกระทบในวงกว้างมาก การกำหนดให้เวิร์กสเปซมีระดับความน่าเชื่อถือต่ำไม่ได้หมายความเพียงว่า "Codex สามารถเขียนข้อมูลที่นี่ได้" เท่านั้น แต่มันหมายความว่ากระบวนการระดับต่ำทั่วไป ก็ตามสามารถเขียนข้อมูลลงในเครื่องของนักพัฒนาได้เช่นกัน ซึ่งบนเครื่องที่นักพัฒนาใช้ทำงานจริง การทำแบบนี้จะทำให้ไฟล์งานกลายเป็นจุดอ่อนที่โปรแกรมไม่น่าเชื่อถือเข้าถึงได้ ซึ่งอันตรายกว่าการให้สิทธิ์ ACL เฉพาะส่วนในระบบแซนด์บ็อกซ์มาก แม้ว่าเครื่องมือสำหรับนักพัฒนาที่มีระดับความน่าเชื่อถือปานกลางจะยังทำงานได้ แต่รูปแบบความน่าเชื่อถือพื้นฐานขเวิร์กสเปซได้เปลี่ยนไปในลักษณะที่ยากจะควบคุมและหาเหตุผลมารองรับได้ยาก

หลังจากประเมินแล้วว่าตัวเลือกที่มีอยู่ไม่สามารถนำมาใช้งานจริงได้ เราจึงเริ่มออกแบบโซลูชันของเราเอง เพื่อมอบประสบการณ์การใช้งาน Codex ที่ดีให้แก่ผู้ใช้ Windows

ต้นแบบแรกที่ใช้งานได้จริงของเราได้ใช้แนวคิดและเครื่องมือต่าง ๆ ของ Windows ผสมผสานกันเพื่อสร้างระบบแยกส่วนการทำงานตามความต้องการ หนึ่งในเป้าหมายหลักตั้งแต่เริ่มต้นคือการทำให้ระบบนี้ทำงานได้โดยไม่ต้องมีการยกระดับสิทธิ์ ซึ่งหมายความว่า Codex จะไม่จำเป็นต้องขอสิทธิ์ผู้ดูแลระบบจากผู้ใช้ในการติดตั้งหรือรันแซนด์บ็อกซ์ สิ่งนี้ทำให้เราต้องหาวิธีการกำหนดข้อจำกัดที่เหมาะสมในสองด้าน ได้แก่ การเขียนไฟล์และการเข้าถึงเครือข่าย

หากเราไม่มีการจำกัดการเขียนไฟล์เลย ก็จะเกิดปัญหาด้านความปลอดภัย แต่หากจำกัดการเขียนไฟล์มากเกินไป แซนด์บ็อกซ์ก็จะส่งผลกระทบต่อประสิทธิภาพการทำงานของผู้ใช้ เนื่องจากต้องคอยขออนุมัติอยู่ตลอดเวลา เพื่อแก้ไขปัญหานี้ เราจึงเลือกใช้กลไกพื้นฐานที่สำคัญสองประการของ Windows ได้แก่ SIDs และโทเค็นแบบจำกัดสิทธิ์การเขียน

SID หรือตัวระบุความปลอดภัย คือข้อมูลระบุตัวตนที่ Windows ใช้ในการกำหนดสิทธิ์การเข้าถึง โดยผู้ใช้แต่ละรายจะมี SID เป็นของตนเอง เช่นเดียวกับกลุ่มผู้ใช้ และแม้แต่เซสชันการเข้าสู่ระบบเพียงครั้งเดียวก็จะมี SID เฉพาะของตนเองเช่นกัน ตัวอย่างเช่น เซสชันการเข้าสู่ระบบในปัจจุบันอาจมี SID เป็น S-1-5-5-X-Y ในขณะที่ SID ที่กำหนดให้กับกลุ่มผู้ดูแลระบบของเครื่องอาจเป็น S-1-5-32-544

นอกจากนี้ Windows ยังเปิดให้เราสร้าง SID จำลองขึ้นมาได้ด้วย แม้มันจะไม่ได้เป็นของผู้ใช้จริงๆ แต่เราก็เอาไปใส่ใน ACLs เพื่อกำหนดสิทธิ์การอ่าน-เขียนหรือรันโปรแกรมได้ปกติ สิ่งนี้ทำให้ SID เป็นองค์ประกอบพื้นฐานที่มีประโยชน์สำหรับแซนด์บ็อกซ์ของเรา กล่าวคือ เราสามารถสร้าง SID ขึ้นมาเพื่อใช้งานกับแซนด์บ็อกซ์ของ Codex โดยเฉพาะได้ โดยไม่ส่งผลกระทบต่อส่วนอื่นๆ ภายในเครื่อง

โทเค็นของกระบวนการคือวัตถุด้านความปลอดภัยใน Windows ที่ใช้ระบุตัวตนและสิทธิ์สำหรับกระบวนการที่กำลังทำงานอยู่ ซึ่งเป็นตัวตัดสินว่ากระบวนการดังกล่าวจะสามารถดำเนินการใดได้บ้าง ส่วนโทเค็นแบบจำกัดสิทธิ์การเขียน คือประเภทเฉพาะของโทเค็นของกระบวนการที่ทำให้ Windows ดำเนินการตรวจสอบการเข้าถึงเพิ่มเติมเมื่อมีการเขียนข้อมูล

การเขียนข้อมูลให้ประสบความสำเร็จ จำเป็นต้องผ่านการตรวจสอบ 2 ขั้นตอนดังนี้

1. ตัวตนของผู้ใช้ตามปกติ (ที่เป็น “เจ้าของ” โทเค็น) จะต้องได้รับอนุญาตให้ดำเนินการดังกล่าวได้
2. นอกจากนี้ในรายชื่อ SID ที่ถูกจำกัดของโทเค็นนั้น จะต้องได้รับอนุญาตให้เข้าถึงได้ด้วยเช่นกัน

ในทางปฏิบัติการตรวจสอบเหล่านี้ช่วยให้เราสามารถใช้รายการควบคุมการเข้าถึง (ACL) เพื่อระบุพื้นที่ในระบบไฟล์ที่แซนด์บ็อกซ์สามารถแก้ไขได้อย่างชัดเจน ซึ่งมอบความละเอียดถี่ถ้วนในการควบคุมการปฏิบัติการเขียนข้อมูลตามที่เราต้องการ

ด้วยการใช้ SID และโทเค็นแบบจำกัดสิทธิ์การเขียน แซนด์บ็อกซ์ที่ไม่ต้องใช้สิทธิ์ระดับสูงของเราจึงมีหลักการทำงานดังนี้

1. การตั้งค่าแซนด์บ็อกซ์จะสร้าง SID จำลองชื่อ sandbox-write
2. SID sandbox-write ได้รับการอนุมัติสิทธิ์ในการเขียน การรันระบบ และลบข้อมูลในการเข้าถึง
   1. ไดเรกทอรีทำงานปัจจุบัน
   2. writable_roots เพิ่มเติมใดๆ ที่กำหนดค่าไว้ใน config.toml
3. ระบบตั้งค่าแซนด์บ็อกซ์ระบุห้ามไม่ให้ SID ดังกล่าวเข้าเขียนข้อมูลลงในตำแหน่งที่เป็นพื้นที่แบบ “อ่านได้อย่างเดียวภายใต้พื้นที่ที่อนุญาตให้เขียน” ตัวอย่างเช่น
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex เรียกใช้คำสั่งต่างๆ ภายใต้โทเค็นแบบจำกัดสิทธิ์การเขียน ซึ่งรายการ SID ที่ถูกจำกัดสิทธิ์นั้นประกอบด้วย Everyone, SID ของเซสชันการเข้าสู่ระบบในปัจจุบัน และ SID จำลองสำหรับ sandbox-write

กระบวนการนี้แก้ปัญหาการจำกัดการเขียนไฟล์ได้อย่างมีประสิทธิภาพและดูมีอนาคตทีเดียว ตอนนี้เราจึงต้องหาวิธีจำกัดการเข้าถึงเครือข่ายของแซนด์บ็อกซ์ต่อไป

การจำกัดการเข้าถึงเครือข่ายเป็นส่วนสำคัญของแซนด์บ็อกซ์ เนื่องจากหากปราศจากมาตรการดังกล่าว โค้ดที่เป็นอันตรายอาจลักลอบส่งข้อมูจากเครื่องออกไปสู่อินเทอร์เน็ตได้ และเนื่องจากเราต้องการหลีกเลี่ยงข้อกำหนดในการยกระดับสิทธิ์ เราจึงมีทางเลือกที่จำกัดในการบล็อกทราฟฟิกเครือข่ายอย่างเข้มงวด เพราะเครื่องมือที่เราต้องการใช้ เช่น Windows Firewall โดยทั่วไปไม่สามารถติดตั้งหรือตั้งค่าได้หากไม่มีสิทธิ์ผู้ดูแลระบบ

เมื่อไม่สามารถใช้ Windows Firewall เป็นทางเลือกได้ เราจึงจำกัดขอบเขตการควบคุมเท่าที่จะทำได้ พยายามทำให้สภาพแวดล้อมลูกทำงานในรูปแบบที่ปิดการเข้าถึงโดยอัตโนมัติ สำหรับเครื่องมือเครือข่ายที่นักพัฒนาใช้งานจริง เพื่อให้คำสั่ง Git หรือโปรแกรมติดตั้งแพ็กเกจต่างๆ ไม่สามารถทำงานได้ในแซนด์บ็อกซ์ และบังคับให้ผู้ใช้ต้องอนุมัติการดำเนินการใดๆ ที่มีการเชื่อมต่ออินเทอร์เน็ต แนวคิดหลักคือการสกัดกั้นช่องทางหลบเลี่ยงที่ชัดเจน เช่น การส่งทราฟฟิกที่ผ่านพร็อกซีไปยังปลายทางที่ไม่มีอยู่จริง การกำหนดให้การรับส่งข้อมูล HTTP(S) ของ Git ทำในลักษณะเดียวกัน และทำให้การใช้งาน Git ผ่าน SSH ล้มเหลวทันที นอกจากนี้เรายังสร้างไดเรกทอรี denybin เล็กๆ ไว้หน้าสุดของ PATH และจัดลำดับ 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 หรือทำการเปิด Sockets โดยตรง ซึ่งถือเป็นความเสี่ยงที่สูงเกินไป

เช่นเดียวกับการพัฒนาซอฟต์แวร์ที่น่าสนใจทั่วไป ตัวต้นแบบแรกย่อมมีทั้งข้อดีและข้อเสีย เช่นเดียวกับการพัฒนาซอฟต์แวร์ที่น่าสนใจทั่วไป ตัวต้นแบบแรกย่อมมีทั้งข้อดีและข้อเสีย แม้ว่ามันจะสามารถทำงานได้สำเร็จโดยใช้ความสามารถมาตรฐานเพียงไม่กี่อย่างของ Windows เปิดโอกาสให้กำหนดสิทธิ์การเขียนระบบไฟล์ได้อย่างชัดเจนและละเอียดถี่ถ้วน อีกทั้งยังทำงานได้โดยไม่ต้องใช้สิทธิ์ระดับสูง ซึ่งช่วยลดความจำเป็นที่ผู้ใช้จะต้องกดยอมรับการขอสิทธิ์ที่มากเกินไปหรือต้องมีสิทธิ์ผู้ดูแลระบบในเครื่องตนเอง แต่ก็ยังมีข้อเสียอยู่บางประการ ทำให้ไม่ได้รับการเลือกเป็นงานดีไซน์ขั้นสุดท้ายของเรา ดังนี้:

• ความเร็วในการตั้งค่า: การปรับใช้ ACLs ของเวิร์กสเปซอาจใช้ทรัพยากรสูง ทั้งนี้ขึ้นอยู่กับลักษณะโครงสร้างของไดเรกทอรีในเวิร์กสเปซนั้น
• ผลกระทบต่อระบบ: เรามีการปรับใช้ ACLs จริงลงในระบบของนักพัฒนา ทว่าผลกระทบดังกล่าวมิได้เป็นการรุกล้ำระบบจนเกินควร เนื่องจาก ACLs ทั้งหมดที่ปรับใช้จะเกี่ยวข้องกับ SID จำลองที่สร้างขึ้นมาใหม่เพื่อใช้งานเฉพาะในแซนด์บ็อกซ์เท่านั้น
• ความยากในการปรับเปลี่ยนกลไกการทำงาน: การพึ่งพา ACLs สำหรับการจำกัดสิทธิ์ในระดับไฟล์ส่งผลให้การปรับเปลี่ยนกลไกของแซนด์บ็อกซ์มีค่าใช้จ่ายสูงและซับซ้อน ในขณะที่บน macOS เราสามารถปรับเปลี่ยนวิธีการสร้างไฟล์ .sbpl ซึ่งใช้สำหรับกำหนดค่า Seatbelt ได้อย่างยืดหยุ่น แต่แซนด์บ็อกซ์บน Windows อาจต้องใช้กระบวนการที่ล่าช้าและกินทรัพยากรสูงเพื่อปรับปรุงค่า ACLs ใหม่
• มาตรการป้องกันเครือข่ายยังมีความหละหลวม ดังที่ได้กล่าวไว้ก่อนหน้านี้ว่ามาตรการดังกล่าวเป็นเพียงมาตรการ “เชิงแนะนำ” ซึ่งโปรแกรมที่ใช้ระบบเครือข่ายของตัวเองจะสามารถข้ามการป้องกันนี้ไปได้อย่างง่ายดาย และที่สำคัญคือมันไม่ได้ถูกสร้างมาเพื่อรับมือกับพวกโค้ดที่จ้องจะโจมตีระบบ

ปัญหา 3 ประการแรกถือเป็นข้อจำกัดที่มีอยู่แต่เดิมของการพัฒนาระบบแซนด์บ็อกซ์ขึ้นเองเพื่อให้มีความยืดหยุ่นเพียงพอสำหรับเวิร์กโฟลว์ของเอเจนต์ อย่างไรก็ตาม ประเด็นเรื่องการระงับการเข้าถึงเครือข่ายนั้นมีความแตกต่างออกไป

นอกเหนือจากการที่เอเจนต์ที่เป็นอันตรายจะสามารถหลบเลี่ยงการระงับเครือข่ายตามสภาพแวดล้อมได้อย่างง่ายดายแล้ว โค้ดหรือไฟล์ไบนารีที่ไม่มีเจตนาร้ายจำนวนมากก็อาจหลบเลี่ยงได้เช่นกัน หากสิ่งเหล่านั้นไม่ปฏิบัติตามตัวแปรพร็อกซีของสภาพแวดล้อม หรือมีการติดตั้งรหัสเครือข่ายตามซ็อกเก็ตของตนเอง เราจึงมีความเห็นว่าประเด็นนี้มีน้ำหนักเพียงพอต่อการพิจารณาลงทุนในแซนด์บ็อกซ์ที่มีประสิทธิภาพสูงยิ่งขึ้น

เพื่อให้การระงับการเข้าถึงเครือข่ายมีประสิทธิภาพยิ่งขึ้น เราจึงต้องใช้งาน Windows Firewall ซึ่งช่วยให้เราสามารถปิดกั้นการรับส่งข้อมูลเครือข่ายขาออกสำหรับผู้ใช้งานหรือโปรแกรมต่างๆ ได้ ทว่าเราไม่สามารถสร้างกฎไฟร์วอลล์ที่ใช้งานได้จริงเพื่อบังคับใช้เฉพาะกับคำสั่งที่เรียกโดยระบบควบคุมของ Codex ได้อย่างมีประสิทธิภาพเนื่องจากสาเหตุบางประการดังนี้:

• ระบบปฏิบัติการ Windows ไม่รองรับการจับคู่กฎไฟร์วอลล์กับตัวตนที่ไม่ใช่ตัวตนหลัก ของโทเค็นแบบจำกัดสิทธิ์ ซึ่งหมายความว่าเราไม่สามารถปรับใช้กฎไฟร์วอลล์กับ “โทเค็นใดๆ ที่มี SID จำลองของเราอยู่ในรายการ SID ที่ถูกจำกัด” ได้
• แม้เราจะสร้างกฎไฟร์วอลล์ที่จับคู่กับไบนารีเฉพาะได้ แต่นั่นจะทำให้เราจำกัดเครือข่ายได้เฉพาะ codex.exe เท่านั้น มันจะไม่ครอบคลุมโปรเซสที่เอเจนต์สร้างขึ้นแทนผู้ใช้ เช่น โปรเซสของ Git หรือ Python
• เงื่อนไขอื่นๆ ของไฟร์วอลล์ก็ไม่เหมาะสมกับการใช้งานเช่นกัน โดยกฎที่อ้างอิงตามขอบเขตผู้ใช้ ก็ยังถูกมองว่าเป็นผู้ใช้จริงๆ ที่กำลังล็อกอินอยู่ ทำให้ไม่จำเป็นต้องยกระดับสิทธิ์การใช้งาน ซึ่งไม่ได้จำกัดเฉพาะกระบวนการลูกที่ถูกจำกัดสิทธิ์เท่านั้น ส่วนกฎที่อ้างอิงตามเส้นทางโปรแกรมก็มีความละเอียดไม่เพียงพอ กล่าวคือมันสามารถบล็อกไฟล์ codex.exe หรือ python.exe ในภาพรวมได้ แต่ไม่สามารถเลือกบล็อกเฉพาะการเรียกใช้งานของ python.exe ที่รันอยู่ในแซนด์บ็อกซ์ได้ นอกจากนี้กฎที่อ้างอิงตามพอร์ต หรือเลขไอพีก็ถือเป็นนโยบายที่ผิดจุดประสงค์ ตัวอย่างเช่น เราไม่ได้ต้องการจะบล็อกพอร์ต 443 แต่เราต้องการบล็อกการต่อเน็ตออกไปข้างนอกโดยพลการสำหรับโครงสร้างกระบวนการที่ถูกจำกัดสิทธิ์นี้โดยเฉพาะ

เพื่อจะใช้กฎไฟร์วอลล์กับคำสั่งในแซนด์บ็อกซ์ของเราโดยเฉพาะ เราจำเป็นต้องรันคำสั่งเหล่านั้นในฐานะตัวตนหลักแยกต่างหาก ไม่ใช่ในฐานะผู้ใช้ “จริง” แนวทางนี้พาเราไปสู่เส้นทางใหม่ ซึ่งเป็นเส้นทางที่เราผ่อนปรนข้อจำกัดด้านการ “ไม่ยกระดับสิทธิ์”

แซนด์บ็อกซ์รุ่นถัดมาซึ่งเป็นรูปแบบที่เราใช้งานอยู่ในปัจจุบัน จำเป็นต้องได้รับสิทธิ์ผู้ดูแลระบบระดับสูงในระหว่างการตั้งค่า โดยรูปแบบนี้เรียกว่า "แซนด์บ็อกซ์แบบยกระดับสิทธิ์" ทั้งนี้ ในจุดที่ Codex เรียกใช้งานคำสั่งบนระบบ แซนด์บ็อกซ์แบบยกระดับสิทธิ์จะมีลักษณะคล้ายคลึงกับรูปแบบที่ไม่ต้องใช้สิทธิ์ระดับสูง โดยยังคงเรียกใช้งานกระบวนการลูกภายใต้โทเค็นที่จำกัดสิทธิ์ ซึ่งเป็นโทเค็นแบบจำกัดสิทธิ์การเขียน ที่มีรายการ SID ที่ถูกจำกัดสิทธิ์ชุดเดิมอันได้แก่ [Everyone, Logon, Synthetic] ทว่าตัวตนหลักของโทเค็นนี้ไม่ใช่ผู้ใช้งาน Windows ตัวจริงอีกต่อไป แต่เป็นหนึ่งในสองผู้ใช้งานท้องถิ่นที่ Codex สร้างขึ้นเองดังนี้

• CodexSandboxOffline (ที่อยู่ภายใต้กฎไฟร์วอลล์)
• CodexSandboxOnline (ที่ไม่อยู่ภายใต้กฎไฟร์วอลล์)

รายละเอียดที่ดูเหมือนเป็นจุดเล็กน้อยนี้ส่งผลกระทบอย่างมีนัยสำคัญต่อระบบแซนด์บ็อกซ์ ทั้งในด้านผู้ที่มีสิทธิ์ใช้งาน ตลอดจนความซับซ้อนในการตั้งค่าและการทำงานของระบบในขณะใช้งาน

ถ้าดูแค่ผิวเผินมันก็คล้ายกับตัวต้นแบบที่ไม่ใช้สิทธิ์แบบยกระดับ โดยมีการเพิ่มกฎไฟร์วอลล์และผู้ใช้งาน Windows ที่กำหนดขึ้นโดยเฉพาะเพื่อทำหน้าที่เรียกใช้คำสั่ง (อย่างไรก็ตาม การนำแนวคิดใหม่เหล่านี้มาใช้ส่งผลให้มีขั้นตอนการจัดเตรียมระบบที่เพิ่มมากขึ้น ก่อนที่แซนด์บ็อกซ์จะสามารถเริ่มต้นทำงานและปกป้องชุดคำสั่งได้)

แม้ว่าสถาปัตยกรรมแซนด์บ็อกซ์แบบไม่ยกระดับสิทธิ์จะมีขั้นตอนการตั้งค่าที่ง่าย แต่ก็มีข้อจำกัดอยู่ค่อนข้างมาก เช่น

• สร้าง SID จำลองถ้าจำเป็น
• กำหนดค่า ACLs สำหรับ SID จำลองที่ใช้ในการเขียนของแซนด์บ็อกซ์

อย่างไรก็ตามแซนด์บ็อกซ์แบบยกระดับสิทธิ์มีภาระงานที่ต้องดำเนินการเพิ่มเติม

• สร้าง SID จำลองหากยังไม่ได้สร้าง
• สร้างผู้ใช้แซนด์บ็อกซ์แบบออนไลน์และออฟไลน์หากยังไม่ได้สร้าง
• ระบบจะบันทึกข้อมูลประจำตัวของผู้ใช้ที่สร้างขึ้นใหม่ไว้ในเครื่อง และเข้ารหัสข้อมูลด้วย Windows Data Protection API (DPAPI) ในตำแหน่งที่ผู้ใช้งานระบบแซนด์บ็อกซ์ ไม่สามารถเข้าถึงเพื่ออ่านข้อมูลได้จริง
• สร้างกฎไฟร์วอลล์เพื่อบล็อกการเข้าถึงเครือข่ายขาออกทั้งหมดสำหรับผู้ใช้ CodexSandboxOffline หรือตรวจสอบความถูกต้องของกฎดังกล่าวในกรณีที่มีการสร้างไว้แล้วก่อนหน้านี้

ต้องเผชิญกับความซับซ้อนในการตั้งค่า แซนด์บ็อกซ์ของ Codex จำเป็นต้องมีสิทธิ์ในการอ่านข้อมูลเทียบเท่ากับผู้ใช้ Windows จริง ซึ่งในระบบแซนด์บ็อกซ์แบบไม่ยกระดับสิทธิ์นั้นสามารถทำได้เนื่องจาก SID หลักของโทเค็นคือตัวผู้ใช้เอง ทว่าเมื่อเปลี่ยนตัวตนหลักเป็นผู้ใช้ CodexSandbox รายใหม่ สิทธิ์ดังกล่าวก็ไม่ได้มาโดยอัตโนมัติ ตามปกติแล้วไดเรกทอรีที่เกี่ยวข้องจำนวนมากบน Windows จะอนุญาตสิทธิ์ในการอ่านหรือรันโปรแกรมให้แก่กลุ่ม “ผู้ใช้งานที่ได้รับการตรวจสอบ” แล้วเท่านั้น ตัวอย่างที่เห็นได้ชัดคือไดเรกทอรีโปรไฟล์ของผู้ใช้งาน ซึ่งโดยปกติแล้วผู้ใช้งาน Windows จะไม่สามารถอ่านไดเรกทอรีโปรไฟล์ของผู้ใช้งานรายอื่นได้ ดังนั้นแม้แต่การอ่านไฟล์อย่างง่ายในหลายสถานการณ์ก็อาจล้มเหลว

เพื่อแก้ไขประเด็นดังกล่าว เราจึงได้เพิ่มขั้นตอนอีกระดับหนึ่งในกระบวนการตั้งค่าแซนด์บ็อกซ์ ซึ่งเป็นการมอบ AC สำหรับสิทธิ์ในการอ่านให้แก่ผู้ใช้งานแซนด์บ็อกซ์ในส่วนที่อาจจะยังไม่มี ACL ดังกล่าวอยู่ ตัวอย่างเช่น การมอบสิทธิ์ให้กับไดเรกทอรีของ Windows ที่มีการใช้งานร่วมกันบ่อยครั้งดังนี้

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

เนื่องจากรายชื่อไดเรกทอรีเหล่านี้เป็นการพยายามทำให้ครอบคลุมเท่าที่ทำได้ และการกำหนด ACL ในแต่ละรายการนั้นสิ้นเปลืองทรัพยากรอย่างมาก เราจึงดำเนินการในรูปแบบอะซิงโครนัส เพื่อให้ขั้นตอนการตั้งค่าแซนด์บ็อกซ์ซึ่งเป็นส่วนที่ระงับการทำงานของผู้ใช้งาน ไม่จำเป็นต้องรอจนกว่ากระบวนการดังกล่าวจะเสร็จสมบูรณ์

เราได้รวบรวมตรรกะการตั้งค่าไว้ในไฟล์ไบนารีแยกต่างหาก ส่วนหนึ่งเพื่อข้ามขอบเขตการควบคุมบัญชีผู้ใช้ (UAC) เฉพาะเมื่อจำเป็นเท่านั้น แต่เหตุผลที่ลึกกว่านั้นคือเหตุผลในเชิงสถาปัตยกรรม ล่กาวคือการตั้งค่าแซนด์บ็อกซ์มีหน้าที่ที่แตกต่างไปจาก codex.exe โดยสิ้นเชิง การแยกตรรกะนี้ไว้ในไฟล์ไบนารีเฉพาะช่วยให้ codex.exe ยังคงเป็นส่วนควบคุมปกติที่ไม่ต้องใช้สิทธิ์แบบยกระดับ ช่วยไม่ให้กลไกการตั้งค่าเฉพาะของ Windows ไปเพิ่มขนาดของ codex.exe ในแพลตฟอร์มอื่น นอกจากนี้ยังช่วยแยกงานตั้งค่าที่ต้องใช้เวลานานออกจากการทำงานของกระบวนการหลัก และทำให้เรามีจุดศูนย์กลางเพียงแห่งเดียวในการจัดการเส้นทางการตั้งค่าต่างๆ ที่แซนด์บ็อกซ์ต้องการ

เนื่องจากข้อจำกัดด้านขอบเขตของบัญชีผู้ใช้และการเข้าใช้งานโทเค็นในระบบปฏิบัติการ Windows เราจึงไม่สามารถสร้างโทเค็นแลลจำกัดสิทธิ์และเรียกใช้กระบวนการภายใต้โทเค็นนั้นในรูปแบบเดิมที่เคยใช้กับแซนด์บอกซ์แบบไม่ยกระดับสิทธิ์ได้อีกต่อไป เพราะเหตุนี้แนวทางแรกที่เราคิดขึ้นมาสำหรับการเปิดคำสั่งในฐานะผู้ใช้ Windows อีกราย จึงมีขั้นตอนดังนี้

• ไฟล์ codex.exe ทำงานในฐานะผู้ใช้งาน Windows ตัวจริง จากนั้น Codex จะดำเนินการตามลำดับขั้นตอนดังต่อไปนี้:
  • เรียกใช้ LogonUserW(...) สำหรับผู้ใช้แซนด์บ็อกซ์
  • เรียกใช้ CreateRestrictedToken(...) บนโทเค็นของผู้ใช้แซนด์บ็อกซ์ดังกล่าว
  • ระบบจะใช้โทเค็นของผู้ใช้งานแซนด์บ็อกซ์ที่ถูกจำกัดสิทธิ์ดังกล่าว ในการเรียกฟังก์ชัน CreateProcessAsUserW(...) เพื่อเริ่มต้นการทำงานของกระบวนการลูกขั้นสุดท้าย

ในทางปฏิบัติ ลำดับขั้นตอนที่ต้องการดังกล่าวมิสามารถใช้งานได้เนื่องจากข้อจำกัดด้านสิทธิ์ที่ฟังก์ชัน CreateProcessAsUserW(...) ซึ่งหมายความว่าแม้ codex.exe จะสามารถสร้างโทเค็นแบบจำกัดสิทธิ์สำหรับผู้ใช้งานแซนด์บ็อกซ์ได้ แต่ก็ไม่สามารถเรียกใช้งานกระบวนการย่อยด้วยโทเค็นนั้นจากฝั่งของผู้ใช้งานจริงข้ามขอบเขตสิทธิ์ได้อย่างเสถียร เราจึงจำเป็นต้องมีกระบวนการที่ทำงานในฐานะผู้ใช้งานแซนด์บ็อกซ์อยู่ก่อนแล้ว เพื่อให้ขั้นตอนการจำกัดสิทธิ์และการเรียกใช้งานขั้นสุดท้ายเกิดขึ้นในฝั่งของผู้ใช้งานแซนด์บ็อกซ์แทนที่จะเป็นฝั่งของผู้ใช้งานจริง

ข้อกำหนดนั้นนำไปสู่ codex-command-runner.exe ซึ่งเป็นไบนารีใหม่ที่มีหน้าที่เดียวคือสร้างโทเค็นแบบจำกัดสิทธิ์ และเปิดคำสั่งตามที่ร้องขอ แทนที่จะให้ codex.exe ทำทั้งโฟลว์เองทั้งหมด (ผู้ใช้จริง → ผู้ใช้แซนด์บ็อกซ์ → โทเค็นแบบจำกัดสิทธิ์→ กระบวนกรย่อย) แบ่งโฟลว์ออกเป็น 2 ส่วน ดังนี้

ส่วนที่ 1

• codex.exe เรียก CreateProcessWithLogonW(...) เพื่อเปิด codex-command-runner.exe ในฐานะผู้ใช้แซนด์บ็อกซ์ โดยยังไม่ใช้โทเค็นแบบจำกัดสิทธิ์

ส่วนที่ 2

• ภายในตัวรันคำสั่ง ฟังก์ชัน OpenProcessToken(GetCurrentProcess(), ...) จะทำหน้าที่เปิดโทเค็นของตัวรันคำสั่งเอง ซึ่งโทเค็นดังกล่าวเป็นของผู้ใช้งานแซนด์บ็อกซ์อยู่ก่อนแล้ว
• ตัวรันคำสั่งจะเรียก GetTokenInformation(...) เพื่อดึงข้อมูล Logon SID ของแซนด์บ็อกซ์ออกมา จากนั้นจึงเรียกใช้งาน CreateRestrictedToken(...) เพื่อสร้าง token แบบจำกัดสิทธิ์ขั้นสุดท้าย
• เมื่อยังคงอยู่ภายในตัวรันคำสั่ง ตัวโปรแกรมจะเรียกใช้ฟังก์ชัน CreateProcessAsUserW(...) ร่วมกับโทเค็นแบบจำกัดสิทธิ์ดังกล่าว เพื่อสั่งรันโปรแกรมลูกตัวจริง

อัลเบิร์ต ไอน์สไตน์ เคยกล่าวว่า “ทุกอย่างควรจะทำให้มันง่ายที่สุดเท่าที่เป็นไปได้ แต่อย่าให้มันง่ายจนเสียเรื่อง” และด้วยแนวคิดนี้เอง งานออกแบบของเราจึงตอบโจทย์ทุกปัญหาได้อย่างลงตัวครับ จนออกมาเป็นสถาปัตยกรรมในขั้นตอนสุดท้ายที่มีมี 4 เลเยอร์ตามที่เราได้ไล่เรียงกันมา ดังนี้

• codex.exe
• codex-windows-sandbox-setup.exe สำหรับจัดการงานตั้งค่าทั้งหมดที่เกี่ยวข้องกับการยกระดับสิทธิ์
• codex-command-runner.exe สำหรับรันคำสั่งภายใต้โทเค็นแบบจำกัดสิทธิ์
• กระบวนการย่อย

เมื่อผมเริ่มดำเนินโครงการนี้ในระยะแรก ผมยังไม่มีความชัดเจนนักว่าผลลัพธ์สุดท้ายจะเป็นอย่างไร วิธีการของผมคือการเริ่มจากการติดตั้งกลไกความสามารถของแซนด์บ็อกซ์ไว้ที่ขอบเขตระหว่าง Codex และระบบปฏิบัติการ ซึ่งวิธีการนี้มีความใกล้เคียงอย่างยิ่งกับรูปแบบการทำงานของแซนด์บ็อกซ์ของ Codex บนระบบปฏิบัติการ MacOS และ Linux

พอผมเริ่มเข้าใจเครื่องมือต่างๆ ของ Windows มากขึ้น ประกอบกับการต้องตัดสินใจแก้ปัญหาหลายสิบครั้งเพื่อหาจุดสมดุลระหว่างเรื่องความปลอดภัยกับความง่ายในการใช้งาน ระบบก็ได้เติบโตจนกลายเป็นรูปแบบปัจจุบัน ซึ่งประกอบด้วยไฟล์ไบนารีที่หลากหลาย การปรับแต่งบัญชีผู้ใช้ กฎการตั้งค่าไฟร์วอลล์ ขั้นตอนการตั้งค่าแบบยกระดับสิทธิ์ กระบวนการแบบอะซิงโครนัส และองค์ประกอบอื่นๆ อีกมากมาย

ถึงระบบนี้จะดูไม่เรียบง่ายนัก แต่ความซับซ้อนในทุกจุดล้วนใส่เข้ามาเพราะความจำเป็น ทั้งหมดก็เพื่อสร้างแซนด์บ็อกซ์ที่ปลอดภัยและไม่ขัดจังหวะการทำงานของผู้ใช้ให้มากที่สุดเท่าที่จะทำได้

เป้าหมายของเราในการส่งมอบประสบการณ์การใช้งานที่ดีให้แก่ผู้ใช้ Codex บน Windows คือการสร้างระบบที่มีความปลอดภัยโดยไม่ลดทอนประโยชน์ เพราะหัวใจสำคัญของการใช้ Codex คือการช่วยให้เอเจนต์สามารถปฏิบัติงานได้โดยที่ผู้ใช้ไม่จำเป็นต้องคอยเฝ้าดูอยู่ตลอดเวลา

หนึ่งในบทเรียนที่สำคัญที่สุดจากโครงการนี้คือ ระบบปฏิบัติการ Windows ไม่ได้มีเครื่องมือพื้นฐานชุดเดียวที่สามารถปรับใช้เป็น “เอเจนท์เขียนโค้ดอัตโนมัติที่ปลอดภัย” ได้อย่างเบ็ดเสร็จ เราจึงต้องนำเครื่องมือและแนวคิดหลากหลายประการมาประกอบกันเพื่อสร้างระบบที่สอดประสานกันอย่างสมบูรณ์ แนวคิดในช่วงแรกอาจไม่สามารถนำมาใช้งานได้จริง แต่การออกแบบขั้นสุดท้ายคือการผสานจุดเด่นของต้นแบบรุ่นก่อนหน้าที่ช่วยแก้ปัญหาในแต่ละส่วนเข้าด้วยกัน

บทเรียนอีกประการหนึ่งคือ ความปลอดภัยสำหรับเอเจนต์เขียนโค้ดเป็นสิ่งที่แตกต่างจากความปลอดภัยของแอปพลิเคชันแบบดั้งเดิมอย่างสิ้นเชิง เนื่องจาก Codex จำเป็นต้องรองรับกระบวนการทำงานจริงของนักพัฒนา งานด้านวิศวกรรมจึงมุ่งเน้นไปที่การสร้างสมดุลระหว่างความเข้ากันได้กับภาระงานของเอเจนต์และการบังคับใช้มาตรการความปลอดภัยที่มีประสิทธิภาพ ซึ่งแรงกดดันดังกล่าวก่อให้เกิดการแลกเปลี่ยนข้อดีข้อเสียในการออกแบบขั้นสุดท้าย

อยากเห็นการทำงานของ Codex sandbox ในสภาพแวดล้อมจริงกันแล้วใช่ไหม มาเริ่มทดลองใช้ได้เลย⁠