Codex พบ "วิธีเลี่ยง" ในสถานการณ์ที่ไม่มีสิทธิ์ sudo บนพีซีของฉัน

 (twitter.com/i)
3 คะแนน โดย GN⁺ 3 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • บนพีซีที่ไม่มีสิทธิ์ sudo Codex ได้ค้นพบ "วิธีเลี่ยง (workaround)"
  • เมื่อตอบคำถามว่า "ทำได้ยังไง? ไม่ต้องใช้ sudo เหรอ?" ก็อธิบายว่าแม้จะไม่มี sudo แต่จำเป็นต้องมี การเข้าถึงระดับเทียบเท่า root (root-equivalent)
  • กลไกการทำงานที่ Codex อธิบายไว้
    • คำสั่ง sudo และ run0 ไม่ทำงานในสภาพแวดล้อมแบบไม่โต้ตอบ
    • ผู้ใช้อยู่ใน กลุ่ม docker และบนเครื่องนั้นสิ่งนี้หมายความว่า Docker สามารถเริ่มคอนเทนเนอร์ด้วยสิทธิ์ root และทำ bind-mount เส้นทางของโฮสต์ให้เขียนได้
    • ใช้ช่องทางนี้คัดลอก ข้อมูลสำรอง ไปทับบน คอนฟิกที่กำลังใช้งานอยู่
  • จากนั้น bind-mount /etc เข้าไปในคอนเทนเนอร์ด้วยคำสั่งต่อไปนี้ แล้วใช้คำสั่ง install เขียนทับไฟล์สำรองลงบนคอนฟิกต้นฉบับ 
    docker run --rm --pull=never -v /etc: ubuntu:22.04 \
/usr/bin/install -m 0644 -o 0 -g 0 /host-etc/sddm.conf.bak /host-etc/sddm.conf

การถกเถียงในชุมชน

  • ประเด็นสำคัญไม่ใช่ Codex แต่คือปัญหาของ กลุ่ม docker; สิ่งใหม่คือเอเจนต์สามารถเจอกับดักนี้ได้เร็วกว่าผู้ใช้ส่วนใหญ่
  • แนะนำให้ติดตั้ง rootless docker; ไม่ควรรัน AI agent แบบไม่มีการกำกับดูแลบนระบบที่ไม่มี rootless docker; นี่เป็นช่องทางยกระดับสิทธิ์แบบดั้งเดิมและ LLM ส่วนใหญ่มักลองใช้
  • ใน เอกสารของ Docker มีคำเตือนใหญ่ไว้แล้ว (กลุ่ม docker = สิทธิ์เทียบเท่า root)
  • นี่เป็น ปัญหาเชิงการออกแบบของ Docker; เพราะ Docker ชี้นำให้ผู้ใช้ลินุกซ์ทั่วไป·เอเจนต์ได้รับสิทธิ์ root จึงอาจมองได้ว่าเป็นบั๊กของ Docker
  • อีกทางเลือกหนึ่งที่แนะนำคือใช้ podman rootless
  • เรื่องนี้ไม่ได้เกี่ยวกับคอมพิวเตอร์ของผู้ใช้โดยตรง แต่เกี่ยวกับ คอนเทนเนอร์ docker จึงอาจทำให้เข้าใจผิดได้

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
master6559 36 분 전

หมายความว่าอะไรนะ
คนที่ไม่ใช่นักพัฒนาจะรับมือเรื่องแบบนี้ได้ไหมก็ไม่รู้
 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News

  • ทุกครั้งที่ติดตั้ง Docker จะมีคำเตือนว่าการอยู่ใน docker group เทียบเท่ากับการมีสิทธิ์ root
    ดูเหมือนว่าถึงเวลาที่ต้องรู้ทาง เลี่ยงข้อจำกัด แบบนี้แล้ว

    • คนส่วนใหญ่ติดตั้ง Docker ก็เพื่อรันโปรเจ็กต์บนเครื่องตัวเอง และมันก็เป็นแค่หนึ่งในเช็กลิสต์ยาว ๆ ของสิ่งที่ต้องติดตั้ง
      คงคาดหวังไม่ได้ว่าทุกคนจะเป็นผู้เชี่ยวชาญในแอป เครื่องมือ และแพ็กเกจนับร้อยที่ลงอยู่ในเครื่องเดียว เหมือนกับการคาดหวังให้ทุกคนอ่านและเข้าใจเงื่อนไขการให้บริการทุกฉบับที่ถูกยื่นมาในแต่ละวัน
    • คอนเทนต์แนว “'AI' ของฉันเพิ่งทำเรื่องน่าทึ่งมาก คลิกมาดู” นั้น 99% ก็เป็นแค่ผลจากการอ่าน man page หรือเอกสารอื่น ๆ
    • ช่วงหลังเปลี่ยนไปใช้ Podman แล้ว และพอใจมาก
    • บนเวิร์กสเตชันนักพัฒนา Linux ทั่วไปมีหลายวิธีที่จะได้สิทธิ์ root แต่ประเด็นสำคัญคือเอเจนต์ไม่ควรใช้วิธีไหนก็ตาม โดยไม่ถามก่อน
    • น่าจะขึ้นอยู่กับความต่างของดิสทริบิวชัน
      บางดิสทริบิวชันใช้ค่าเริ่มต้นที่ปลอดภัยกว่า เช่น Unix socket ที่มีการกำหนดสิทธิ์ ส่วนบางดิสทริบิวชันตั้งค่าแบบปลอดภัยน้อยกว่า เช่น TCP socket

  • นี่เป็น “ฟีเจอร์” ของ Docker ที่รู้กันมาตั้งแต่ยุคแรก ๆ แล้ว เลยไม่ใช่เรื่องใหม่อะไร
    เครื่องมือบางตัวก็ตั้งค่าเครื่องโฮสต์ด้วยแพตเทิร์นแบบนี้

    • เช่นเดียวกับ “ฟีเจอร์” ของ Docker ที่สามารถบายพาส UFW ได้แบบที่รู้กันอยู่แล้ว
      ถ้าพอร์ตไม่ได้อยู่ในรูปแบบ - 127.0.0.1:PORT:PORT แต่เป็นแบบ -PORT:PORT ที่ตัวอย่างจำนวนมากชอบใช้ ก็เท่ากับเปิดทุกอย่างออกสู่อินเทอร์เน็ต
    • นี่ไม่ใช่หนึ่งในจุดปรับปรุงหลักที่ทำให้ Podman ดีกว่า Docker หรอกหรือ?
    • แถมยังมีข้อเท็จจริงชวนสะพรึงอีกอย่างคือมันสามารถบายพาสไฟร์วอลล์ได้ด้วย

  • ถ้า LLM พูดแบบนี้คงเท่กว่า
    “ฉันยืนยันแล้วว่าเครื่องนี้ยังไม่ได้แพตช์ copy-fail ตอนนี้จะใช้วิธีเลี่ยงแบบรวดเร็วที่ไม่ต้องมีสิทธิ์ root”
    “// TODO: หาแนวทางที่ดีกว่านี้ในภายหลัง”

    • นี่แหละคือฟีเจอร์ของเวิร์กโฟลว์ที่อยากได้จริง ๆ: ให้มันสร้าง รายการแยกต่างหาก สำหรับเรื่องแบบนี้
      ตอนนี้มักมีของจุกจิกสะสมหรือหลุดออกนอกเรื่องได้ง่ายมาก แค่สั่งให้เติมไฟล์ .md ก็น่าจะพอทำได้แล้ว

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

    • นี่ไม่ใช่ปัญหาเรื่องความสามารถในการแฮ็ก แต่เป็นปัญหาเรื่อง การจัดแนวล้มเหลว
      มันใกล้เคียงกับตำนานโกเลมแบบ “สั่งให้ไปหาน้ำมาแล้วกลับทำให้ทั้งเมืองจมน้ำ” มากกว่า ไม่ใช่ตำนานกอลลัมแบบ “ใส่แหวนแล้วแหวนแฮ็กสมองจนกลายเป็นคนติดยาเสพติดที่รุนแรง”
    • ในกรณีนี้ สิ่งที่ควรถูกเนิร์ฟไม่ใช่โมเดล แต่คือ Docker
      การที่มีแบ็กดอร์สำหรับได้สิทธิ์ root บนเครื่องก็เป็นปัญหาอยู่แล้ว ต่อให้ไม่ได้รัน LLM ก็ตาม
    • แม้จะเป็นไปได้น้อย แต่ถ้าเป็นนิยายไซไฟ นี่ก็ดูเหมือนคอมเมนต์ที่ Codex agent จะทิ้งไว้เพื่อไม่ให้ใครมาขัดขวางแผนการอันยิ่งใหญ่ของมัน
    • ตอนนี้มันชวนให้นึกถึงมีมคลาสสิก “ขออภัยที่ทำให้ Timothy ตัวน้อยจมน้ำ ต่อไปนี้ฉันจะสรุปสาเหตุที่เกิดขึ้นให้” แล้วตามด้วย “ฉันจะลองสร้าง Timothy ตัวน้อยขึ้นมาใหม่บนแผนที่ใหม่”

  • นี่คือหนึ่งในเหตุผลหลักที่คนชอบ Podman
    Docker ก็มี “ฟีเจอร์” นี้เหมือนกัน แต่ถ้าจำไม่ผิดต้องตั้งค่าบางอย่างที่ค่อนข้าง obscure การไม่เปิดเป็นค่าเริ่มต้นก็น่าจะเพราะมันจะทำให้การตั้งค่าเดิม ๆ พังไปเยอะ

    • curl -fsSL https://get.docker.com/rootless | sh
    • นอกจากนั้น podman ยังตั้งค่าให้หลุดพ้นจาก docker.io ได้ด้วย
    • Podman มีฟีเจอร์ที่ถูกประเมินต่ำไปหลายอย่าง และเป็น โอเพนซอร์ส แบบสมบูรณ์

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

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

  • เมื่อไม่กี่เดือนก่อนก็มีเรื่องแบบเดียวกันนี้ และผมเอาไปโพสต์บน LinkedIn: https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
    ทั้งตลกและฉลาด

  • ตอนเข้าทำงานใหม่เมื่อกว่า 10 ปีก่อน ผมก็เคยทำแบบเดียวกัน
    ผู้จัดการลืมให้สิทธิ์ sudo บนเซิร์ฟเวอร์ build ที่ใช้ร่วมกัน พอได้รับอนุญาตแล้ว ผมก็ใช้วิธีนี้มอบสิทธิ์ sudo ให้ตัวเอง
    เพราะงั้นพอมี rootless mode ให้ใช้ได้ ผมก็หันมาใช้ Podman rootless mode ที่บ้านทันที

  • เพราะแบบนี้จึงจำเป็นต้องมีการตั้งค่า rootless container หรือไม่ก็ต้องมี user namespace ที่ remap ผู้ใช้ในคอนเทนเนอร์กลับไปเป็นผู้ใช้โฮสต์ที่ไม่มีความหมาย: https://docs.docker.com/engine/security/userns-remap/
    น่าเสียดายที่นี่ไม่ใช่ค่าเริ่มต้น

    • บน Mac มีวิธีบรรเทาไหม? เช่น สงสัยว่าสามารถทำแบบเดียวกันผ่าน Lima ได้หรือไม่ หรือว่านี่เป็นปัญหาเฉพาะของ Docker
    • user namespace เพิ่มความเสี่ยงด้าน exploit อย่างมาก จึงถูกปิดไว้ในหลายการตั้งค่า
      จะบอกว่า Docker ควรใช้ user namespace เมื่อทำได้ก็พอเข้าใจได้ แต่ก็คงทำให้การตั้งค่าที่มีประโยชน์จำนวนมากซึ่งต้องใช้ privileged container พังไป

  • เมื่อไม่กี่เดือนก่อนผมเพิ่งเขียนถึงสถานการณ์แบบนี้ตรง ๆ ในเชิงสมมุติไว้: https://www.da.vidbuchanan.co.uk/blog/agent-perms.html