วิธี จำกัด เชลล์ของผู้ใช้ที่อนุญาตให้เรียกใช้โปรแกรมเชลล์

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

คำถามของคุณควรเป็น:

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

ฉันจะป้องกันระบบและผู้ใช้ของฉันจากผู้ใช้ของฉันได้อย่างไร

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

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

มีสามสิ่งที่จำเป็นต้องมีเพื่อให้สามารถทำสิ่งที่คุณต้องการได้อย่างเต็มที่:

1. เปลือกที่กำหนดเองที่ไม่มีคำสั่งที่คุณกำลังสนใจใน นี่เป็นเรื่องยากที่จะได้รับ แต่ถ้าคุณไม่ต้องการให้ผู้ใช้เข้าถึงเชลล์แบบดั้งเดิมอย่างแท้จริงนี่เป็นวิธีเดียวที่จะลบพวกมันออกได้
2. สิทธิ์ของแฟ้มตั้งอย่างถูกต้อง ไม่ต้องการให้ผู้ใช้ระบบเสียหายหรือไม่ ตั้งค่าการอนุญาตเพื่อไม่ให้ระบบเสียหายแม้ว่าจะมีเครื่องมือที่เหมาะสม ในสามขั้นตอนนี้เป็นขั้นตอนที่ง่ายที่สุด
3. Technoloy ใช้การควบคุมการเข้าถึงบังคับเช่น AppArmor MACs เช่น AppArmor และ SELinux ฝังสิทธิ์ในเคอร์เนล สิ่งเหล่านี้ป้องกันผู้ใช้จากการเรียกใช้เครื่องมือที่ถูกต้องแม้ว่าพวกเขาจะพบพวกเขาที่ไหนสักแห่ง (และชอบสิทธิ์ของไฟล์ป้องกันพวกเขาจากการใช้พวกเขานอกกรอบ จำกัด )

เข็มขัดสายแขวนและปืนหลักเพื่อการวัดที่ดี ยากที่จะไปผิดที่นั่น

AppArmor มีความน่าสนใจเนื่องจาก MAC สำหรับการปฏิบัติการที่เฉพาะเจาะจงนั้นสืบทอดมาโดยลูก ๆ ของมันทั้งหมด ตั้งค่าการเข้าสู่ระบบของผู้ใช้/bin/bash-bobตั้งค่าโปรไฟล์ AppArmor สำหรับสิทธิไบนารีที่เฉพาะเจาะจงและวิธีเดียวที่พวกเขาออกจากคุกได้รับอนุญาตนั้นคือการใช้ประโยชน์จากเคอร์เนล หากสคริปต์การติดตั้งแบบสันหลังยาวเหลือ/var/opt/vendor/tmpบางส่วนที่สามารถเขียนได้แบบโกลบอลด้วยเหตุผลโง่ ๆ ผู้ใช้ที่ใช้/bin/bash-bobเป็นเชลล์จะไม่สามารถเขียนได้ ตั้งค่าโปรไฟล์ bash-bob เพื่ออนุญาตให้เขียนไปยังโฮมไดเร็กตอรี่ของตนเองเท่านั้น/tmp, และไม่สามารถยกระดับความผิดพลาดของการอนุญาตดังกล่าวได้ ถึงแม้ว่าพวกเขาอย่างใดค้นหารหัสผ่านรากโปรไฟล์ AppArmor สำหรับ/bin/bash-bobจะยังคงมีผลบังคับใช้แม้กระทั่งหลังจากที่พวกเขาsuขึ้นตั้งแต่ปีsuและbashกระบวนการ spawns /bin/bash-bobมันเป็นลูกของ

ส่วนที่ยากคือการสร้างโปรไฟล์ AppArmor

1. สร้างโปรไฟล์ AppArmor สำหรับ / bin / bash-bob และตั้งเป็นโหมดการตรวจสอบ
2. ตั้งค่าล็อกอินเชลล์ของ Bob เป็น / bin / bash-bob
3. เข้าสู่ระบบเป็น Bob ทำทุกสิ่งที่คุณต้องการให้ Bob สามารถทำได้
4. ใช้ auditlog เพื่อสร้างโปรไฟล์ AppArmor (SUSE มีเครื่องมือสำหรับสิ่งนี้ไม่แน่ใจเกี่ยวกับ distros Linux อื่น ๆ ) นี่เป็นเรื่องน่าเบื่ออย่างมาก แต่ต้องเกิดขึ้นหากคุณต้องการระดับความปลอดภัยนี้
   1. คุณจะทำสิ่งต่าง ๆ เช่น:
      • อนุมัติการเข้าถึงเพื่ออ่านของไลบรารีระบบส่วนใหญ่
      • การอนุมัติสิทธิในการอ่านและดำเนินการกับคำสั่งระบบที่ได้รับอนุญาตไม่กี่ตัวที่เลือก
      • กำลังอนุมัติการเข้าถึงเพื่อเขียนช่องว่างชั่วคราว
      • การอนุมัติการสร้างซ็อกเก็ตหากจำเป็น
5. กำหนดนโยบายเพื่อบังคับใช้
6. เข้าสู่ระบบในชื่อ Bob ทำสิ่งต่างๆ
7. ทำการปรับเปลี่ยน

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

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

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

อย่าพยายาม จำกัด คำสั่งและ จำกัด สิทธิ์ของไฟล์ คุณไม่สามารถ จำกัด การเข้าถึง syscalls ของผู้คนได้ดังนั้นทุกคนที่ต้องทำคือจัดเตรียมสำเนาคำสั่ง "อันตราย" ของตนเองที่คุณไม่ต้องการให้พวกเขาทำ

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

ในการตั้งค่าเชลล์แบบ จำกัด ผู้ใช้ให้ตั้งค่า/bin/rbash(หรือคล้ายกันเชลล์ส่วนใหญ่เข้าสู่โหมด จำกัด เมื่อไบนารีชื่อR *** name *) เป็นเชลล์ผู้ใช้ จากนั้นแก้ไข **. bashrc (หรือเทียบเท่า) และตั้งค่า$PATHเป็นไดเรกทอรีที่จัดเก็บไบนารี / สคริปต์ที่ได้รับอนุญาตทั้งหมด

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

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

คุณอาจต้องการลอง [lshell] [1] (เชลล์ จำกัด )

lshell เป็นเชลล์ที่เข้ารหัสใน Python ที่ให้คุณ จำกัด สภาพแวดล้อมของผู้ใช้ในการ จำกัด ชุดคำสั่งเลือกเปิดใช้งาน / ปิดการใช้งานคำสั่งใด ๆ กับ SSH (เช่น SCP, SFTP, rsync, ฯลฯ ) คำสั่งของผู้ใช้ และอื่น ๆ.

[1]: http://lshell.ghantoos.org/Overview lshell

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

• ผู้ใช้ไม่ได้อยู่ในwheelกลุ่มเดียวที่ได้รับอนุญาตให้ใช้งานsu(บังคับใช้ผ่าน PAM)

• ผู้ใช้จะได้รับการรักษาความปลอดภัยอย่างถูกต้อง rbashด้วยการอ่านอย่างเดียวPATHชี้ไปที่ส่วนตัว~/binนี้~/bin/ไดเรกทอรีมีลิงค์ไปยังสาธารณูปโภคง่ายๆ

  $ ll ~/bin
  total 0
  lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
  lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
  lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
  lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
  lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
  lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
  

• ผู้ใช้จะได้รับการ จำกัด สภาพแวดล้อมการอ่านอย่างเดียว (คิดว่าสิ่งที่ชอบLESSSECURE, TMOUT, HISTFILEตัวแปร)

• ผู้ใช้จะถูกจับคู่ให้กับผู้ใช้ SELinux staff_uและได้รับสิทธิในการรันคำสั่งในฐานะผู้ใช้อื่น ๆ sudoที่จำเป็นต้องผ่าน

• ผู้ใช้เป็น/home, /tmpและอาจ/var/tmpจะ polyinstantiated ผ่าน/etc/security/namespace.conf:

  /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
  /var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
  $HOME      $HOME/$USER.inst/              tmpdir:create   root
  

  นอกจากนี้ยังทำให้ไฟล์โครงกระดูกทั้งหมดอ่านได้อย่างเดียวสำหรับผู้ใช้และเป็นเจ้าของโดย/etc/security/namespace.initroot

วิธีนี้คุณสามารถเลือกได้ว่าจะ$USERสามารถดำเนินการคำสั่งใด ๆ ในนามของตนเอง (ผ่านลิงก์ใน~/binไดเรกทอรีส่วนตัวจัดเตรียมผ่าน/etc/skelตามที่อธิบายไว้ข้างต้น) ในนามของผู้ใช้รายอื่น (ผ่านsudo) หรือไม่มีเลย

ใช่เพียงแค่เปลี่ยนการอนุญาตในคำสั่งเหล่านี้

คุณอาจมีโอกาสในการต่อสู้ที่ดีขึ้นโดยการเขียนคำสั่งเชลล์ที่ทำงานตามความต้องการของคุณ

การอนุญาตเริ่มต้นสำหรับผู้ใช้ปกติบน Linux ไม่เหมาะสมอะไร