root / superuser สามารถอ่านไฟล์ที่ป้องกันการอ่านได้หรือไม่?


34

บนโฮสติ้ง unix ที่ใช้ร่วมกันถ้าฉันมีไฟล์ sensitive-data.txt และฉันมีปัญหา:

chmod 600 sensitive-data.txt

ผู้ใช้รูทยังอ่านไฟล์ของฉันได้ไหม? โดยเฉพาะฉันสงสัยว่าจะปลอดภัยที่จะเก็บรหัสผ่านของฉันในไฟล์ hgrc mercurial

UPDATE

ตัดสินใจที่จะใช้ส่วนขยายของพวงกุญแจ mecurial เนื่องจากมันง่ายในการติดตั้ง:

pip install mercurial_keyring

แล้วเพิ่มใน hgrc:

[extensions]
mercurial_keyring =

อย่างไรก็ตามฉันยังสนใจที่จะตอบคำถามนี้

คำตอบ:


61

ใช่รากสามารถ:

$ echo Hello you\! > file
$ chmod 600 file
$ ls -l file
-rw------- 1 terdon terdon 11 Feb 27 02:14 file
$ sudo -i
# cat file
Hello you!

ไม่ว่าในกรณีใด ๆ แม้ว่ารูทจะไม่สามารถอ่านไฟล์ของคุณในฐานะรูทได้ก็ตามพวกเขาสามารถเข้าสู่ระบบได้ตลอดเวลาโดยไม่ต้องใช้รหัสผ่าน:

$ whoami
terdon
$ sudo -i
[sudo] password for terdon: 
# whoami 
root
# su - terdon
$ whoami
terdon

ดังนั้นrootสามารถเปลี่ยนเป็นชื่อผู้ใช้อื่น ๆ ที่ใช้su(หรือsudo -iu username) และจากนั้นจะสามารถทำอะไรได้เลยราวกับว่าคุณเป็นคุณ


23

สันนิษฐานเสมอว่าroot(และผู้ใช้ / กระบวนการอื่น ๆ ด้วยCAP_DAC_OVERRIDEและCAP_DAC_READ_SEARCH) สามารถทำทุกอย่างได้เว้นแต่ว่า LSM (SELinux, AppArmor หรือคล้ายกัน) ป้องกันไม่ให้เขาทำเช่นนั้น

นั่นหมายความว่าคุณควรถือว่าการกดแป้นทั้งหมดของคุณสามารถอ่านได้ รหัสผ่านไม่ปลอดภัยจริงๆ หากคุณต้องการความปลอดภัยระดับร้ายแรงคุณต้องใช้ระบบที่ควบคุมโดยคุณอย่างสมบูรณ์ (และไม่ได้ใช้โดยบุคคลอื่น)


นี่เป็นปัญหาของฉันเกี่ยวกับความสามารถตามที่ใช้งานอยู่ในปัจจุบัน เนื่องจากพวกเขาไม่ได้ระบุเป้าหมายคุณต้องมีการบังคับใช้ประเภทที่แทนที่ความสามารถ (เช่น SELinux) เพียงเพื่อป้องกันไม่ให้เกิดขึ้น การให้ผู้ใช้CAP_DAC_OVERRIDEหนึ่งคนมอบสิทธิพิเศษทั้งหมดที่พวกเขาต้องการเพื่อแทนที่กลไกการรักษาความปลอดภัยอื่น ๆ ในระบบ เป็นพื้นCAP_DAC_OVERRIDE CAP_DO_WHATEVER_YOU_WANT
Bratchley

10

ใช่รากมีสิทธิ์ทั้งหมดที่จะทำอะไร

ที่นี่คุณสามารถเห็นฉันได้สร้างการทดสอบชื่อไดเรกทอรีและสัมผัสไฟล์ lonston.txt และแสดงรายการไฟล์

root@system99:/tmp# mkdir test && touch lonston.txt && ls -l
total 4
-rw-r--r-- 1 root root    0 Feb 27 16:35 lonston.txt
drwxr-xr-x 2 root root 4096 Feb 27 16:35 test

จากนั้นฉันเปลี่ยนสิทธิ์ของไฟล์และ Directory เป็นสิทธิ์ null โดยใช้ 000 และแสดงรายการเพื่อดูสิทธิ์

root@system99:/tmp# chmod 000 lonston.txt && chmod 000 test && ls -l
total 4
---------- 1 root root    0 Feb 27 16:35 lonston.txt
d--------- 2 root root 4096 Feb 27 16:35 test

จากนั้นแม้ฉันสามารถเขียนไปยังไฟล์และอ่านไฟล์โดยใช้ cat

root@system99:/tmp# echo "Yes root have all Privileges than other user's, let we see the permission of user's too" > lonston.txt 

root@system99:/tmp# cat lonston.txt 
Yes root have all Privilages than other user's, let we see the permission of user's too

แม้ฉันจะสามารถเข้าไปในไดเรกทอรีที่มีสิทธิ์ d --------- (null) 000 รูทแม้แต่ไม่มีสิทธิ์อ่านหรือเขียน

root@system99:/tmp# cd test/
root@system99:/tmp/test# pwd
/tmp/test

แม้ฉันสามารถสร้างไฟล์และโฟลเดอร์หลังจากการเปลี่ยนแปลงการอนุญาตจากที่ใดก็ได้

root@system99:/tmp/test# touch /tmp/test/lonston/testdir/babin.txt

root@system99:/tmp/test# ls -l /tmp/test/lonston/testdir/
total 0
-rw-r--r-- 1 root root 0 Feb 27 16:39 babin.txt

ตอนนี้ที่นี่เราสามารถเห็นการอนุญาตด้วย 400

root@system99:/tmp/test# chmod 400 babin.txt

รายการเพื่อดูการอนุญาตของไฟล์

root@system99:/tmp/test# ls -l
total 8
-r-------- 1 root root   34 Feb 27 16:42 babin.txt
drwxr-xr-x 3 root root 4096 Feb 27 16:38 lonston

การใช้ vim im i ได้เพิ่ม 1 บรรทัดไปยังไฟล์ babin.txt

root@system99:/tmp/test# vim babin.txt

แต่ในขณะที่อยู่ในโหมด vim จะสังเกตเห็นเรา W10: คำเตือน: การเปลี่ยนไฟล์แบบอ่านอย่างเดียว แต่ก็ยังเขียนได้

ตอนนี้เราสามารถ cat ไฟล์สำหรับการส่งออก

root@system99:/tmp/test# cat babin.txt 
hi this is the write persmission 
this is added while the file have 400 permission

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

root@system99:/tmp# exit
exit

นำทางไปยัง / tmp Directory

sysadmin@system99:~$ cd /tmp/
sysadmin@system99:/tmp$ ls -l
total 8
---------- 1 root root   88 Feb 27 16:36 lonston.txt
d--------- 2 root root 4096 Feb 27 16:35 test

แต่ในขณะที่อ่านไฟล์จากผู้ใช้ปกติเราไม่สามารถทำได้

sysadmin@system99:/tmp$ cat lonston.txt 
cat: lonston.txt: Permission denied

sysadmin@system99:/tmp$ cd test/
cat: test/: Permission denied

เพียงเท่านี้หวังว่าคุณจะได้พลังของผู้ใช้รูท

หากคุณอยู่ในผู้ใช้ปกติหากคุณต้องการรูทสิทธิ์เราจำเป็นต้องใช้ sudo มันจะถามรหัสผ่าน sudo

ตัวอย่าง:

sysadmin@system99:/tmp$ sudo cat lonston.txt 
[sudo] password for sysadmin: 
Yes root have all Privilages than other user's, let we see the permission of user's too

ผู้ใช้ Sudo มีการร่วมมือกับกลุ่มผู้ใช้รูทดังนั้น sudo ใดที่มีสิทธิ์ใช้งานรูท

หากต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับ sudo

# man sudoers

ที่นี่เราสามารถเห็นพวกเขาได้นิยามไว้ว่าผู้ใช้ปกติสามารถมีสิทธิ์ Sudo ได้เพียงไม่กี่บรรทัดที่ฉันได้กล่าวถึงที่นี่

sysadmin@system99:/tmp$ sudo cat /etc/sudoers

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

ทั้งหมดที่เราสามารถอ่านหรือแก้ไขหรือลบไฟล์ได้แม้รากไม่ได้รับอนุญาตให้อ่าน


2
ทำไมคำตอบนี้มี upvotes น้อยมาก? ครอบคลุมเกือบทุกกรณีที่อาจเกิดขึ้นกับตัวอย่าง
Foo Bar

8

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

(ความหวาดระแวงเป็นสิ่งที่ยอดเยี่ยมไม่เคยมีเพียงพอ ;-)

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


3

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


2

ใช่รูทสามารถอ่านไฟล์ที่มีการป้องกันแม้ในขณะที่เจ้าของไม่สามารถ (ในขณะที่เจ้าของสามารถลบการป้องกันแล้วอ่านเนื้อหา):

echo "123" > abc.txt
chmod 000 abc.txt
cat abc.txt

cat: abc.txt: การอนุญาตถูกปฏิเสธ

su
cat abc.txt

123

อย่างไรก็ตามภายใต้การตั้งค่าปกติรูทไม่สามารถเข้าถึงไฟล์ที่ได้รับการป้องกันในระบบไฟล์ระยะไกลเช่น NFS ("root squash")


+1 สำหรับการกล่าวถึงสควอชรูทของ NFS อย่างไรก็ตามตราบใดที่รูทสามารถ su ให้กับผู้ใช้ที่เป็นเจ้าของไดเร็กทอรีที่เมาท์ NFS แล้วสควอชรูทยังคงไม่ปกป้อง
เจนนี่ D

2

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

ตัวเลือกการเข้ารหัส:

  1. เข้ารหัสไฟล์ธรรมดาและป้องกันไม่ให้ทุกคนยกเว้นว่าคุณจะสามารถดูได้
  2. เข้ารหัสเชลล์สคริปต์และทำให้เวอร์ชันที่เข้ารหัสสามารถเรียกใช้งานได้ แต่ยังป้องกันไม่ให้ทุกคนสามารถแก้ไขหรือดูได้

หากเลือกตัวเลือกที่ 1 ต่อไปนี้เป็นวิธีการเข้ารหัสไฟล์ของคุณ:

cat (your-file) | openssl aes-128-cbc -a -salt -k "(specify-a-password)" > (your-file).enc

หากต้องการถอดรหัสไฟล์ด้านบนคุณเรียกใช้คำสั่งดังนี้:

cat (your-file).enc | openssl aes-128-cbc -a -d -salt -k "(specify-the-password)" > (your-file).dec

- คุณอาจต้องการใส่สคริปต์ด้านบนเพื่อไม่ให้ปรากฏในประวัติของคุณ หรือคุณสามารถลบพารามิเตอร์ " -k " ซึ่งจะแจ้งให้ openssl ถามรหัสผ่านของคุณ

หากเลือกตัวเลือกที่ 2 เพียงคัดลอกและวางสคริปต์ของคุณไปยังไซต์ต่อไปนี้:

http://www.kinglazy.com/shell-script-encryption-kinglazy-shieldx.htm

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

  1. wget link-to-the-zip-file
  2. แตกไฟล์ zip ที่ดาวน์โหลดมาใหม่
  3. cd / tmp / KingLazySHIELD
  4. ./install.sh / var / tmp / KINGLAZY / SHIELDX- (ชื่อสคริปต์ของคุณ) / home / (ชื่อผู้ใช้ของคุณ) - บังคับใช้

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.