คำสั่ง BusyBox ถูกสร้างขึ้นอย่างแท้จริงหรือไม่?

ฉันอ่านUnix Recovery Legend ที่มีชื่อเสียงและมันทำให้ฉันสงสัยว่า:

หากฉันเปิดเชลล์ BusyBox และไบนารี BusyBox ถูกลบไปเองฉันจะยังสามารถใช้คำสั่งทั้งหมดที่รวมอยู่ในไบนารี BusyBox ได้หรือไม่

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

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

ถ้า (1) เป็นวิธีการทำงานของ BusyBox ฉันคาดหวังว่าคำสั่ง BusyBox ที่ระบุจะไม่สามารถใช้งานได้จากภายในอินสแตนซ์ที่กำลังทำงานของ BB หลังจากที่ลบไบนารี BB

ถ้า (2) เป็นวิธีการทำงาน BusyBox สามารถใช้งานได้แม้กระทั่งการกู้คืนระบบที่ตัว BB เองถูกลบไป - หากยังมีอินสแตนซ์ที่ใช้งานได้ของ BusyBox ที่สามารถเข้าถึงได้

เอกสารนี้มีอยู่ทุกที่หรือไม่? ถ้าไม่มีวิธีทดสอบอย่างปลอดภัยหรือไม่?

busybox system-recovery

— Wildcard
แหล่งที่มา

is there a way to safely test it?ดาวน์โหลดopenwrtอิมเมจทั่วไป x86 และแนบภาพไปที่เครื่อง VirtualBox ใหม่

— อ่าง

และนี่ทำให้เกิดคำถามว่าคำสั่ง Busybox จะทำงานต่อไปหลังจากที่PATHไม่ได้ตั้งค่าได้อย่างไร มันถือว่าเป็นค่าเริ่มต้นPATHหรือไม่?

— muru

@muru: จากซอร์สโค้ด (อย่างน้อยก็สำหรับ ash clone) มันดูเหมือนว่ามันจะใช้ PATH ที่ไม่มีการตั้งค่าเหมือนกับสตริงที่ว่างเปล่าดังนั้นมันจึงค้นหาไดเรกทอรีปัจจุบันเท่านั้น

— Henning Makholm

@HenningMakholm ดีความคิดเห็นของฉันตอบโดย Gilles 'คำตอบ อย่างไรก็ตามมันเป็นเรื่องที่ดีที่จะรู้ว่า - ฉันคาดหวังว่าจะได้สร้างเฉพาะงานภายใน

— muru

คำตอบ:

ตามค่าเริ่มต้น BusyBox จะไม่ทำอะไรเป็นพิเศษเกี่ยวกับแอปเพล็ตที่สร้างขึ้น (คำสั่งในรายการbusybox --help)

อย่างไรก็ตามหากเปิดใช้งานFEATURE_SH_STANDALONEและFEATURE_PREFER_APPLETSตัวเลือกในเวลารวบรวมเมื่อ BusyBox sh¹ดำเนินการคำสั่งซึ่งเป็นชื่อแอปเพล็ตที่รู้จักมันจะไม่ทำการPATHค้นหาตามปกติแต่จะเรียกใช้แอปเพล็ตในตัวผ่านทางลัดแทน:

แอปเปิลที่ถูกประกาศว่าเป็น“ noexec” ในซอร์สโค้ดจะถูกดำเนินการเมื่อการเรียกใช้ฟังก์ชันในกระบวนการแยก ในฐานะของ BusyBox 1.22 applets ต่อไปนี้ noexec: chgrp, chmod, chown, cksum, cp, cut, dd, dos2unix, env, fold, hd, head, hexdump, ln, ls, md5sum, mkfifo, mknod, sha1sum, sha256sum, sha3sum, sha512sum, sort, ,tacunix2dos
แอปเปิ้ลที่ถูกประกาศว่าเป็น“ nofork” ในซอร์สโค้ดจะถูกดำเนินการเมื่อการเรียกใช้ฟังก์ชันในกระบวนการเดียวกัน ในฐานะของ BusyBox 1.22 applets ต่อไปนี้ nofork: [[, [, basename, cat, dirname, echo, false, fsync, length, logname, mkdir, printenv, printf, pwd, rm, rmdir, seq, sync, test, true, usleep, ,whoamiyes
แอพเพล็ตอื่น ๆ จะถูกดำเนินการจริง ๆ (ด้วยforkและexecve) แต่แทนที่จะทำการPATHค้นหา BusyBox จะดำเนินการ/proc/self/exeถ้ามี (ซึ่งโดยปกติจะเป็นกรณีบน Linux) และเส้นทางที่กำหนดไว้ในเวลารวบรวม

docs/nofork_noexec.txtนี้เป็นเอกสารในรายละเอียดอีกเล็กน้อยใน การประกาศของแอพเพล็ตอยู่ในinclude/applets.src.hซอร์สโค้ด

การกำหนดค่าเริ่มต้นส่วนใหญ่จะปิดคุณสมบัติเหล่านี้เพื่อให้ BusyBox ดำเนินการคำสั่งภายนอกเช่นเปลือกอื่น ๆ Debian เปิดฟีเจอร์เหล่านี้ทั้งในbusyboxและbusybox-staticแพ็คเกจ

ดังนั้นถ้าคุณมี BusyBox ที่คอมไพล์แล้วด้วยFEATURE_SH_STANDALONEและFEATURE_PREFER_APPLETSคุณสามารถรันคำสั่ง BusyBox ทั้งหมดจากเชลล์ BusyBox แม้ว่าการปฏิบัติการจะถูกลบ (ยกเว้นแอปเพล็ตที่ไม่ได้อยู่ในรายการด้านบนหาก/proc/self/exeไม่มี)

¹ _{มีจริงสองการใช้งานของ "ดวลจุดโทษ" ใน BusyBox - เถ้าและเงียบ - แต่พวกเขาทำงานในลักษณะเดียวกันในแง่นี้}

— Gilles 'หยุดความชั่วร้าย'
แหล่งที่มา

@ Wildcard FEATURE_PREFER_APPLETSและFEATURE_SH_STANDALONEเป็นธงเวลารวบรวมการเปิดใช้งานหรือปิดการใช้งานคุณสมบัติ แอปเพล็ตถูกทำเครื่องหมายnoforkและnoexecไม่คำนึงถึงการใช้ธง เครื่องหมายดังกล่าวจะมีผลกระทบหรือไม่ขึ้นอยู่กับFEATURE_PREFER_APPLETSการเปิดใช้งาน ดังนั้นสามพฤติกรรมที่เป็นไปได้: 1. FEATURE_PREFER_APPLETSคนพิการ, 2. FEATURE_PREFER_APPLETSเปิดใช้งานและแอปเพล็เป็นnofork3 เปิดใช้งานและแอปเพล็คือFEATURE_PREFER_APPLETS noexecPara สามในเอกสารอธิบายอย่างดี และส่วนสุดท้ายแสดงกรณีที่เป็นไปได้

— muru

@ Wildcard FEATURE_SH_STANDALONE(ซึ่งต้องการFEATURE_PREFER_APPLETS) noforkไม่จำเป็น ด้วยFEATURE_SH_STANDALONE, /proc/self/exeมีการใช้งานที่เหมาะสมจึงจะทำงานแม้ว่า BB ถูกลบ คุณสามารถทดสอบนี้ออกมาพร้อมกับความเสี่ยงน้อยที่สุดเป็นธรรมใด ๆ SYSTM Debian หรือ Arch Linux, วิ่งbusybox ash, unset PATHทำคำสั่งของอ่าง มันใช้งานได้ดี

— muru

บนระบบ Ubuntu 14.04.1 LTS Busybox ได้รับการกำหนดค่าให้เลือกใช้แอปเพล็ต ตั้งแต่ค่าcatมิได้chmodต้อง exec ไอเอ็นจีพา ธ ที่คุณสามารถกู้คืนปฏิบัติการ cat /proc/self/exe > busybox; chmod 755 busyboxthusly:

— Barefoot IO

@forest มีความแตกต่างอย่างมาก: tacต้องการไฟล์อินพุตที่ค้นหาได้ซึ่งไม่สามารถใช้งานได้ตลอดเวลาหรืออ่านอินพุตทั้งหมดลงในหน่วยความจำ catสามารถอ่านอินพุตได้ตั้งแต่ต้นจนจบโดยยกเลิกสิ่งที่ประมวลผลแล้ว มันง่ายกว่าในการนำไปใช้และยังใช้กันอย่างแพร่หลายอีกด้วยดังนั้นจึงเหมาะสมกว่าที่จะปรับให้เหมาะสม

— hvd

@Wildcard Nofork และ noexec เป็นตัวบ่งชี้ที่ตั้งค่าในแต่ละแอปเพล็ต FEATURE_xxxเป็นตัวเลือกเวลารวบรวมสำหรับ BusyBox โดยรวม การบ่งชี้ของ nofork และ noexec นั้นสำคัญหากFEATURE_PREFER_APPLETSมีการใช้งานอยู่ (อย่างน้อยเพื่อวัตถุประสงค์ในการดำเนินการคำสั่งในเชลล์พวกมันยังใช้ในบริบทอื่น ๆ ด้วย)

— Gilles 'หยุดชั่วร้าย'

is there a way to safely test it? ด้วยภาพ openwrt ทั่วไป x86:

คำสั่งส่วนใหญ่จะไม่ได้ในตัว แต่บางคนก็มีเหมือนและecho printfไฟล์ไบนารีที่มีเนื้อหาโดยพลการสามารถสร้างขึ้นโดยใช้printfแต่chmod +xจะมีปัญหา

— อ่าง
แหล่งที่มา

ที่น่าสนใจ; คุณกำลังเรียกใช้นั้นจากภายใน BusyBox ตัวเองหรือเปลือกอื่น ๆ ?

— Wildcard

(นอกจากนี้คุณอยากจะวางในข้อความแทนที่จะเป็นสกรีนช็อตหรือไม่?)

— Wildcard

/bin/ash -> busybox@Wildcard

— อ่างล้างหน้า

ในคำตอบของ Gilles หากFEATURE_SH_STANDALONEเปิดใช้งานคุณจะไม่ได้รับพฤติกรรมนี้ สองmvจะทำงานได้อย่างสมบูรณ์แบบ

— muru