1 คะแนน โดย GN⁺ 2023-11-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการเปิดตัว sudo-rs ซึ่งเป็นการนำ sudo ที่ใช้สำหรับข้าม ขอบเขตสิทธิ์ มาพัฒนาใหม่ด้วย Rust ในเวอร์ชันเสถียรตัวแรก
  • คาดว่าประมาณ 1 ใน 3 ของบั๊กความปลอดภัยใน sudo ต้นฉบับมีสาเหตุมาจากปัญหาการจัดการหน่วยความจำ ซึ่งเป็นแรงผลักดันหลักของการเขียนใหม่ด้วย Rust
  • sudo-rs ลด พื้นผิวการโจมตี โดยตัดฟีเจอร์ที่ใช้งานไม่บ่อยออก และชุดทดสอบยังถูกนำไปใช้ค้นพบบั๊กใน sudo ต้นฉบับด้วย
  • Wolfi Linux OS มี sudo-rs รวมมาแล้ว และ Chainguard มองว่าการปรับปรุงเครื่องมือสำคัญด้านความปลอดภัยเช่นนี้อาจส่งผลต่อทั้งอุตสาหกรรม
  • มีกำหนดเริ่มการตรวจสอบความปลอดภัยจากภายนอกในเดือนกันยายน 2023 และหลังจากนั้นงานจะเดินหน้าสู่ Milestone 4 ที่เน้นฟีเจอร์ระดับองค์กร

sudo-rs ที่เขียนใหม่ด้วย Rust

  • Prossimo เปิดตัว sudo-rs รุ่นเสถียรตัวแรก
  • sudo-rs เป็นโปรเจ็กต์ที่นำยูทิลิตี sudo ซึ่งมักใช้บน Linux เพื่อข้าม ขอบเขตสิทธิ์ ระหว่างบัญชีผู้ใช้กับบัญชีผู้ดูแลระบบ มาพัฒนาใหม่ด้วย Rust
  • โปรเจ็กต์ sudo-rs มุ่งเน้นการยกระดับความปลอดภัยเมื่อเทียบกับ sudo ต้นฉบับ
    • ใช้ Rust เพื่อให้ได้ความปลอดภัยด้านหน่วยความจำ
    • จุดตั้งต้นคือการประเมินว่าประมาณ 1 ใน 3 ของบั๊กความปลอดภัยใน sudo ต้นฉบับเกี่ยวข้องกับปัญหาการจัดการหน่วยความจำ
    • ลด พื้นผิวการโจมตี โดยตัดฟีเจอร์ที่ไม่ค่อยมีการใช้งานออก
    • มีการพัฒนาชุดทดสอบที่ครอบคลุมอย่างมาก และการทดสอบนี้ยังช่วยค้นพบ บั๊กใน sudo ต้นฉบับ ได้ด้วย

การนำไปใช้และขั้นตอนถัดไป

  • Wolfi Linux OS มี sudo-rs รวมมาแล้ว
  • Dan Lorenc ซีอีโอและผู้ร่วมก่อตั้งของ Chainguard มองว่าระหว่างการสร้าง Wolfi นั้น ความปลอดภัยด้านหน่วยความจำ เป็นสิ่งสำคัญสูงสุด และการปรับปรุงเครื่องมือหลักด้านความปลอดภัยอย่าง sudo อาจสร้างผลกระทบอย่างมากต่อทั้งอุตสาหกรรม
  • sudo-rs ถูกพัฒนาโดยทีมร่วมจาก Tweede Golf และ Ferrous Systems ภายใต้สัญญากับ Prossimo
  • โปรเจ็กต์นี้ เริ่มต้น ในเดือนธันวาคม 2022 และการตรวจสอบความปลอดภัยจากภายนอกสำหรับโค้ด sudo-rs มีกำหนดเริ่มในเดือนกันยายน 2023
  • หลังการตรวจสอบ ทีมจะย้ายไปยัง Milestone 4 ของแผนงาน ซึ่งเป็นช่วงที่เน้นฟีเจอร์ระดับองค์กร
  • ยูทิลิตี sudo ที่พัฒนาด้วย C ต้นฉบับ ได้รับการดูแลมาอย่างยาวนานโดย Todd C. Miller และเขายังให้คำแนะนำกับการพัฒนา sudo-rs ด้วย
  • NLnet Foundation ให้ทุนสำหรับการตรวจสอบ sudo-rs และ Amazon Web Services สนับสนุนงานนี้รวมถึงการเปลี่ยนผ่านไปสู่ซอฟต์แวร์ที่ปลอดภัยด้านหน่วยความจำ

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

 
GN⁺ 2023-11-07
ความเห็นจาก Hacker News
  • ในฐานะหนึ่งในผู้พัฒนาดั้งเดิมของ sudo (https://en.wikipedia.org/wiki/Sudo) ฉันได้เห็นมันถูกเขียนใหม่เกือบทั้งหมดและแก้บั๊กมาอย่างต่อเนื่องตลอด 43 ปีที่ผ่านมา
    จะเรียกว่าเป็นคำสั่งบน UNIX ที่ถูกตรวจสอบด้านช่องโหว่มากที่สุดคำสั่งหนึ่งก็ได้ และช่องโหว่ที่พบก็ถูกแก้ไขมาโดยตลอด
    จึงสงสัยว่าทีมพัฒนาเพียงทีมเดียวจะสามารถนำเครื่องมือที่นักพัฒนากับผู้เชี่ยวชาญด้านความปลอดภัยหลายพันคนเคยตรวจดู มาทำใหม่ทั้งหมดโดยไม่สร้างบั๊กใหม่ขึ้นมาเลยแม้แต่ตัวเดียวได้จริงหรือ
    เลยอดคิดไม่ได้ว่าภาษา Rust มีอะไรบางอย่างที่ลบโอกาสเกิดบั๊กออกไปได้อย่างน่าอัศจรรย์ทั้งหมดหรือเปล่า

    • ต้องขอบคุณงานที่สร้าง sudo ขึ้นมาจริง ๆ และคิดว่ามันเป็นเครื่องมือที่มีคุณค่ามากในชีวิตประจำวันของผู้คนจำนวนมาก
      ในมุมของคนที่กำลังทำ sudo-rs เราไม่เคยตั้งใจจะทำให้งานเดิมไร้ความหมาย และโดยเฉพาะในช่วงแรกเราก็รู้ดีว่า implementation ของเราเอง ย่อมไม่ได้ไร้บั๊ก
      สำหรับผมเอง การทำเวอร์ชัน Rust ทำให้สามารถแตะงานในพื้นที่ที่ปกติคงไม่กล้าเข้าไปยุ่ง เพราะไม่มั่นใจมากพอว่าจะเขียนโค้ด C ที่ค่อนข้างปลอดภัยได้
      อย่างน้อยงานนี้ก็ทำให้เราเจอบั๊กบางอย่างใน sudo เดิมได้แล้ว และถึงจะถูกแก้ไขมาตลอด 43 ปี ตราบใดที่สภาพแวดล้อมรอบตัวเปลี่ยนไป ซอฟต์แวร์แบบนี้ก็คงยากจะไร้บั๊กอย่างสมบูรณ์
      ตราบใดที่เรายังร่วมมือกันและเรียนรู้จากงานกับความผิดพลาดของกันและกัน การมี ทางเลือก เพิ่มขึ้นอีกเล็กน้อยก็ไม่ใช่เรื่องเสียหาย
    • ไม่ว่า 43 ปีที่ผ่านมาจะเกิดอะไรขึ้น ในปี 2021 ก็ยังมีช่องโหว่ทำลายหน่วยความจำที่ถูกนำไปใช้โจมตีได้อย่างกว้างขวางชื่อ Baron Samedit อยู่ดี
    • ระบบชนิดข้อมูลขั้นสูง ตัวตรวจสอบการยืม และภาษาแบบ memory-safe ช่วยได้มากอย่างแน่นอน แต่แน่นอนว่าไม่ได้กำจัดบั๊กทั้งหมด
      เวลาทำ RiiR สิ่งที่ดีที่สุดที่นักพัฒนาจะทำได้คือยึดตามแนวปฏิบัติที่ดีและเรียนรู้จากความผิดพลาดในอดีต
      ตลอด 43 ปีที่ผ่านมาเราพัฒนาไปมากแล้ว และแค่เลิกใช้การจัดการสตริงแบบ C ก็ช่วยกำจัดบั๊กได้จำนวนมากก่อนจะไปพูดเรื่อง memory safety เสียอีก
      ทุกวันนี้คนที่อยากสร้างตัวแทน sudo ที่ปลอดภัยก็สามารถทำได้ดีกว่าสมัยก่อนมากแม้จะใช้แค่ C และโครงการ OpenBSD ก็แสดงให้เห็นเรื่องนี้ได้ค่อนข้างดี
      ถ้าตัดจุดอันตรายจำนวนมากที่โค้ด OpenBSD พยายามหลีกเลี่ยงออกไปในระดับภาษา ก็ย่อมได้จุดเริ่มต้นที่ดีกว่า แต่ก็ยังต้องใช้ความระมัดระวังและประสบการณ์อย่างมากอยู่ดี และภาษาการเขียนโปรแกรมก็ทดแทนสิ่งนั้นไม่ได้
      อย่างน้อยมันก็คุ้มค่าที่จะพิจารณาอย่างจริงจัง แต่คงยังไม่ควรถูกแจกจ่ายเป็นค่าปริยายในเร็ว ๆ นี้
    • ไม่ได้จะปฏิเสธคุณค่าของประสบการณ์ และคาดว่าโครงการนี้ก็น่าจะได้ค้นพบความยากลำบากซ้ำอีกแน่ แต่สิ่งสำคัญคือเราไม่จำเป็นต้องทำซ้ำงานทั้งชีวิตของ Newton, Leibniz และ Maxwell แบบเดิมทั้งหมด เพื่อให้เข้าใจฟิสิกส์คลาสสิกอย่างถูกต้อง
      ตอนนี้มันอยู่ในหลักสูตรมัธยมแล้ว ถ้าเรียนผ่านก็ทำได้ค่อนข้างดี และถ้าพยายามเพิ่มอีกหน่อยก็สามารถรับมือสิ่งที่พวกเขาใช้เวลาทั้งชีวิตสร้างขึ้นมาได้อย่างดีมาก
      นั่นเป็นเพราะเราสามารถยืนบน บ่าของยักษ์ ได้ และมีทั้ง hindsight รวมถึงเทคโนโลยีและวิธีการเรียนรู้ที่ดีกว่า โดยไม่จำเป็นต้องทำผิดพลาดแบบเดียวกับพวกเขาทั้งหมดอีก
      ถ้าผู้พัฒนาดั้งเดิมกลับมาเขียน sudo ใหม่ตั้งแต่ต้นด้วยประสบการณ์และความรู้ที่มีตอนนี้ ก็มีโอกาสสูงว่าจะทำมันให้สะอาด เรียบง่าย และใช้เวลาน้อยกว่ามาก
      ไม่ได้หมายถึงการลดทอนความพยายามและประสบการณ์เดิม แต่หมายความว่า การเปลี่ยนประสบการณ์นั้นให้กลายเป็นสิ่งที่ดีกว่าในเวลาที่สั้นลง ไม่ใช่เรื่องที่เป็นไปไม่ได้
    • สำหรับ memory safety ก็จริงที่ภาษาแบบนี้ทำให้ปลอดภัยโดยพื้นฐานได้ดีกว่ามาก แต่ไม่ได้ช่วยอะไรกับบั๊กเชิงตรรกะเลย
      อย่างไรก็ตาม ตอนแทนที่ sudo หรือเครื่องมืออื่นที่เขียนด้วย C ช่องโหว่อย่าง null pointer หรือการใช้บัฟเฟอร์ผิดวิธี มักกินสัดส่วนง่าย ๆ ถึง 50% ของทั้งหมด
  • ผมมองว่าสองประเด็นที่โครงการนี้ชูขึ้นมาคือสิ่งที่มักถูกมองข้ามบ่อยกว่าการใช้ Rust เสียอีก
    คือการตัดฟีเจอร์ที่ใช้น้อยออกเพื่อลด พื้นผิวการโจมตี และการพัฒนาชุดทดสอบขนาดใหญ่ที่ถึงขั้นช่วยค้นพบบั๊กใน sudo เดิมได้ด้วย
    เวลาเขียนโค้ดที่ความปลอดภัยสำคัญ สิ่งเหล่านี้สำคัญยิ่งกว่าการเขียนใหม่ด้วย Rust เสียอีก

    • หมายถึงสำคัญกว่าสิ่งแบบนี้ด้วยหรือ?
      การพิสูจน์ด้วยระบบจัดการการพิสูจน์เชิงรูปนาม Coq: https://coq.inria.fr/
      ตัวอย่างใช้งานจริงดูได้ที่ https://aws.amazon.com/security/provable-security/ และ การตรวจพิสูจน์ด้วยคอมพิวเตอร์ช่วย (CAV) ก็น่าลองดูเช่นกัน
  • ถ้าสมมติว่าเป้าหมายของโปรเจ็กต์นี้คือมาแทน sudo ก็แอบกังวลนิดหน่อยที่ปล่อยผ่านเรื่อง “ตัดฟีเจอร์ที่ใช้น้อยออก” แบบคร่าว ๆ
    สิ่งสำคัญคือฟีเจอร์เหล่านั้นคืออะไร ใช้น้อยแค่ไหน และในการตั้งค่าที่ใช้ฟีเจอร์พวกนั้นจะล้มเหลวอย่างไร
    แก้ไข: ดูเหมือนว่าจะมีการสรุปข้อจำกัดบางส่วนไว้ใน GitHub README, https://github.com/memorysafety/sudo-rs#differences-from-ori...

    • หนึ่งในฟีเจอร์ที่หายไปคือ sudoedit หรือ sudo -e
      ผมใช้บ่อยเวลาแก้ไขไฟล์ใน /etc หรือไฟล์ที่ผู้ใช้ของผมไม่มีสิทธิ์แก้ไข โดยแฟล็กนี้จะคัดลอกไฟล์ไปยังตำแหน่งชั่วคราวที่ผู้ใช้ของผมมีสิทธิ์แก้ไขได้ก่อน จากนั้นรันตัวแก้ไขข้อความด้วย สิทธิ์ของผู้ใช้ผมเอง โดยไม่ใช้สิทธิ์ sudo
      ตัวแก้ไขจะถูกกำหนดด้วยตัวแปรสภาพแวดล้อม $SUDO_EDITOR และหลังจากปิดแล้ว จะคัดลอกไฟล์กลับด้วยสิทธิ์เดิมเฉพาะเมื่อมีการเปลี่ยนแปลงเท่านั้น
      ข้อดีคือมันรันตัวแก้ไขในฐานะผู้ใช้ของผม ไม่ใช่ root จึงโหลดการตั้งค่าและปลั๊กอินของผู้ใช้ผมได้
    • อีกฟีเจอร์หนึ่งที่ไม่ได้ระบุว่าไม่มี คือความสามารถในการรัน make me a sandwich (https://github.com/sudo-project/sudo/blob/main/Makefile.in#L...)
    • อีกความสามารถหนึ่งที่ใช้ในสภาพแวดล้อมขนาดใหญ่ ซึ่งไม่มีทั้งในโรดแมปและยังไม่ถูกทำใน sudo-rs คือ การรองรับ LDAP
      ใน sudo ปกติ คุณสามารถจัดการสิทธิ์ sudo ของทั้งเครือข่ายจากการตั้งค่า LDAP ส่วนกลางได้ และยังสร้างกฎที่จำกัดตามเวลา โฮสต์ ผู้ใช้ และคำสั่งจากศูนย์กลางได้ด้วย
      โดยไม่เสี่ยงที่ความผิดพลาดทางไวยากรณ์เพียงจุดเดียวจะทำให้การตั้งค่าทั้งหมดใช้ไม่ได้ เพราะในกรณีนี้จะมองข้ามเฉพาะกฎข้อนั้น
    • เราก็เคยผ่านกระบวนการย้ายไปใช้ systemd มาแล้ว ดังนั้นแอดมินระบบน่าจะจัดการเรื่องระดับนี้ได้
      น่าจะมีเอกสารทางเทคนิคที่ดีมากแน่นอน และนี่ก็เป็นโพสต์ปล่อยรุ่นเชิงประชาสัมพันธ์ ไม่ใช่ที่สำหรับไปหาลิสต์ฟีเจอร์ที่หายไป
    • การที่หนึ่งในเครื่องมือ UNIX พื้นฐานที่สุดมีฟีเจอร์ยัดเข้ามามากขนาดนี้เองต่างหากที่เป็น สัญญาณอันตราย ที่ใหญ่กว่า
  • เมื่อดูความต่างระหว่าง Apache-2.0+MIT กับ GPL-2.0 คุณอาจได้ su/sudo-rs ที่ปลอดภัยต่อหน่วยความจำ แต่ผู้ที่แจกจ่ายมันในรูปไบนารีไม่จำเป็นต้องเปิดเผยซอร์สโค้ดที่ใช้สร้าง รวมถึงการแก้ไขที่อาจมีอยู่

    • ผมก็อยากเขียนคอมเมนต์นี้เหมือนกัน
      ผมกังวลมากว่าแนวโน้มการเขี่ยเครื่องมือ GPL ออกด้วยการเขียน Rust ใหม่ภายใต้ MIT/Apache วันหนึ่งอาจนำไปสู่ Linux แบบกรรมสิทธิ์ ได้ แต่ sudo เดิมไม่ใช่ GPL
      มันใช้ไลเซนส์สไตล์ ISC/MIT [1]
      1. https://www.sudo.ws/about/license/
    • การหนีออกจาก GPL ในองค์ประกอบแกนกลางแบบนี้เป็นความคิดที่แย่มาก
      ก็ด้วยเหตุผลที่พูดไว้ข้างบน และผมทิ้งคอมเมนต์นี้ไว้เพื่อเน้นประเด็นนี้
    • Sudo ไม่ใช่ GPL แต่เป็นไลเซนส์สาย ISC[0] ที่ผ่อนปรนมาก
      ส่วน su ดูเหมือนจะเป็น GPL จริง
      [0]: https://www.sudo.ws/about/license/
    • มันแย่ขนาดนั้นจริงหรือ?
      คุณก็มีอิสระที่จะไม่ใช้ดิสโทรแบบนั้น
      ในแง่ความปลอดภัย ผู้ไม่หวังดีอาจแจกไบนารีพร้อมแสดงซอร์สโค้ดอีกชุดที่ไม่ตรงกันก็ได้
      ไม่ว่าจะเป็น GPL หรือไม่ก็เหมือนกัน
    • ไม่ว่าจะชอบหรือไม่ การใช้ GPL กำลังลดลง และอนาคตของเคอร์เนล Linux เองก็ไม่ได้รับประกัน
      ในพื้นที่ระบบปฏิบัติการตระกูล UNIX แบบเสรี/โอเพนซอร์สสำหรับ IoT ผู้เล่นทุกเจ้ารวมถึง ZephyrOS ที่ Linux Foundation สนับสนุน ต่างก็ใช้ไลเซนส์ Apache, MIT, BSD ปนกันไป
      เมื่อคนรุ่น GPL หายไปแล้ว ระบบปฏิบัติการตระกูล UNIX ที่มีไลเซนส์ดึงดูดบริษัทใหญ่ได้มากกว่า ก็น่าจะโผล่มาเป็นอีกทางเลือกในการดูแลเคอร์เนล Linux ในอีกไม่นาน
  • คงน่าสนใจถ้าเอาสิ่งนี้ไปจับคู่กับ Debian derivative ที่ใช้ GNU Coreutils เวอร์ชัน Rust
    มันอาจให้ประโยชน์ก้อนใหญ่ทั้งด้านความปลอดภัยของหน่วยความจำและประสิทธิภาพ
    [1] https://github.com/uutils/coreutils

    • ผมสงสัยว่าเรายังห่างจาก user space ของ UNIX ที่ใช้ Rust มากแค่ไหน
      อย่างน้อยก็คงไม่จำเป็นต้องไปทำ C compiler ขึ้นมา
  • นี่คือการขัดเงาของเสียหรือเปล่า?
    แน่นอนว่าการทำใหม่ให้ดีกว่านั้นเป็นเรื่องดี แต่คุณไม่ได้ตกใจกับฟีเจอร์ประหลาด ๆ ของ sudo บ้างหรือ?
    แม้แต่ส่วนที่ดูธรรมดาก็ยังแปลกและละเอียดอ่อนมากพอจะเปราะบางได้
    คนที่ใช้ sudo แบบ “ลึก ๆ” น่าจะลองคิดดูว่ามี วิธีอื่น ไหม

  • น่าจะดีถ้ามี แฟล็กหรือเครื่องมือสำหรับตรวจสอบ/ยืนยัน ที่ลองรันการตั้งค่า sudo ปัจจุบัน แล้วบอกว่าส่วนไหนที่ sudo-rs ยังไม่รองรับ
    โปรเจ็กต์แบบนี้ควรมีตัวช่วยย้ายระบบเพื่อให้การเปลี่ยนผ่านราบรื่น

  • ถ้าจำไม่ผิด ช่องโหว่ sudo ช่วงหลัง ๆ ล้วนเป็น ข้อผิดพลาดเชิงตรรกะ ไม่ใช่ปัญหาความปลอดภัยของหน่วยความจำ
    การเขียนใหม่เป็นเรื่องดี แต่ก็ไม่ควรทำเหมือนกับว่าแค่เพราะเขียนใหม่แล้วจะไม่มีทางใส่บั๊กใหม่จากการเข้าใจการทำงานผิดหรือความผิดพลาดธรรมดา ๆ เข้าไปได้

    • 2021: https://nvd.nist.gov/vuln/detail/CVE-2021-3156
      2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634
    • มีใครกำลังทำเหมือนนั้นอยู่หรือ?
      ผมเห็นการอ้างเรื่องความปลอดภัยของหน่วยความจำเยอะก็จริง แต่ดูไม่เหมือนว่าโปรเจ็กต์นี้กำลังบอกว่าบั๊กประเภทอื่นจะถูกกำจัดออกไปอย่างแน่นอน
    • ในทำนองเดียวกัน sudo เดิมเองก็อาจมี บั๊กหน่วยความจำ ใหม่ ๆ หลุดเข้ามาได้
      การลดพื้นผิวการโจมตีด้วยการตรวจสอบแบบสแตติกดูเหมือนจะคุ้มค่ากว่าในระยะยาว
  • doas เป็นเครื่องมือที่ง่ายกว่ามากสำหรับงานแบบเดียวกัน
    ผมไม่ค่อยเข้าใจว่าทำไมมันถึงไม่ถูกใช้มากกว่านี้

  • doas มีขนาด 43184 ไบต์ และทำทุกอย่างที่ฉันต้องการได้ครบ
    ช่องโหว่ของ sudo นั้นเป็นสัญญาณเตือน
    ถ้ายังไม่ได้ย้าย ลองใช้ opendoas (แพ็กเกจ Debian) ก็น่าสนใจ

    • ใช้ doas บน Linux อยู่หรือ?
      ยังไม่ป้องกันการโจมตีแบบ tty pushback: https://github.com/Duncaen/OpenDoas/issues/106
      เป็นปัญหาความปลอดภัยที่ยังไม่ได้แก้ไขและค่อนข้างร้ายแรง