Mengapa mount memerlukan hak akses root?


54

Mengapa Linux mengharuskan pengguna untuk melakukan root / menggunakan sudo / secara khusus diotorisasi per mount untuk me-mount sesuatu? Sepertinya keputusan apakah akan mengizinkan pengguna memasang sesuatu harus didasarkan pada hak akses mereka ke volume sumber / jaringan berbagi dan ke titik pemasangan. Beberapa kegunaan untuk pemasangan non-root adalah pemasangan gambar sistem file ke arah yang dimiliki pengguna dan pemasangan berbagi jaringan ke direktori milik pengguna. Sepertinya jika pengguna memiliki kontrol atas kedua sisi persamaan mount semuanya harus keren.

Klarifikasi pembatasan akses:

Saya merasa saya harus bisa me-mount apa pun yang pengguna akan memiliki akses ke titik-mount bahwa pengguna adalah pemilik.

Sebagai contoh, di komputer saya / dev / sda1 dimiliki oleh root pengguna dan disk grup dengan izin brw-rw----. Oleh karena itu pengguna non-root tidak dapat mengacaukan / dev / sda1 dan jelas me-mount seharusnya tidak memungkinkan mereka untuk me-mount. Namun jika pengguna memiliki /home/my_user/my_imagefile.img dan mount point / home / my_user / my_image / mengapa mereka tidak bisa me-mount file gambar itu pada mount point itu dengan:

mount /home/my_user/my_imagefile.img /home/my_user/my_image/ -o loop

Seperti yang ditunjukkan kormac, ada masalah suid. Jadi beberapa pembatasan harus ditambahkan untuk mencegah suid menjadi masalah serta berpotensi beberapa masalah lainnya. Mungkin salah satu cara untuk melakukan ini adalah membuat OS memperlakukan semua file sebagai milik pengguna yang melakukan pemasangan. Namun untuk sederhana baca / tulis / eksekusi, saya tidak melihat mengapa ini akan menjadi masalah.

Gunakan kasus:

Saya memiliki akun di lab tempat ruang rumah saya dibatasi hingga 8GB. Ini kecil dan sangat menjengkelkan. Saya ingin memasang volume nfs dari server pribadi saya untuk meningkatkan jumlah ruang yang saya miliki. Namun, karena Linux tidak mengizinkan hal-hal seperti itu saya terjebak dengan scp'ing file bolak-balik untuk tetap di bawah batas 8GB.


4
Kedengarannya masalahnya bukan karena "linux tidak mengizinkan hal-hal seperti itu" karena Anda tidak diperbolehkan melakukan hal-hal seperti itu di lab Anda, karena sistem dapat dikonfigurasi untuk memungkinkan Anda melakukannya. Anda dapat mendiskusikan masalah ini dengan orang-orang yang mengelola sistem; jika mereka tidak ramah, maka itu tentang politik dan bukan komputer;)
goldilocks

Apakah mungkin untuk me-mount titik mount yang sewenang-wenang yang memiliki akses normal? Sepertinya administrator harus menambahkan baris eksplisit ke fstab untuk mount nfs saya agar diizinkan. Pada gilirannya ini kemungkinan akan menjadi preseden di mana mereka juga harus melakukan itu untuk semua orang yang meminta, yang dapat saya pahami tidak dapat dipertahankan. Oleh karena itu pertanyaan mengapa Linux tidak memungkinkan Anda untuk me-mount hal-hal yang sewenang-wenang yang akan aman (dalam beberapa cara terbatas).
CrazyCasta

10
Sudahkah Anda mencoba sshfs? Ini akan memasang direktori jarak jauh, melalui ssh, seperti Anda sendiri, tanpa perlu akses root. Hanya perlu FUSE (Filesystem di UserSpacE) untuk diinstal.
Arcege

1
Anda telah mendengar tentang masalah hard drive yang buruk, dll. Jadi, saya tahu saya telah mengatakan ini berkali-kali, tetapi filosofinya adalah bahwa "memasang hal-hal yang sewenang-wenang" tidak dapat dibuat aman , dan itulah mengapa ia mengaturnya seperti itu. adalah (pengecualian khusus harus diatur). BTW, jika Anda tidak memiliki FUSE, sftpsedikit lebih baik untuk digunakan daripada scp.
goldilocks

1
Sepertinya (variasi) ini telah ditanyakan di sini sebelumnya: Memasang file loop tanpa izin root?
Daniel Pryden

Jawaban:


37

Ini adalah batasan historis dan keamanan.

Secara historis, sebagian besar drive tidak dapat dilepas. Jadi masuk akal untuk membatasi pemasangan pada orang yang memiliki akses fisik yang sah, dan mereka kemungkinan akan memiliki akses ke akun root. Entri fstab memungkinkan administrator untuk mendelegasikan pemasangan ke pengguna lain untuk drive yang dapat dilepas.

Dari sudut pandang keamanan, ada tiga masalah utama yang memungkinkan pengguna sewenang-wenang untuk memasang perangkat blok sewenang-wenang atau gambar sistem file di lokasi yang sewenang-wenang.

  • Pemasangan ke lokasi yang tidak dimiliki membayangi file di lokasi itu. Misalnya: pasang sistem file pilihan Anda /etc, dengan /etc/shadowkata sandi root yang berisi yang Anda ketahui. Ini diperbaiki dengan memungkinkan pengguna untuk me-mount sistem file hanya pada direktori yang dimilikinya.
  • Driver sistem file sering belum diuji secara menyeluruh dengan sistem file yang cacat. Driver sistem file buggy dapat memungkinkan pengguna yang memasok sistem file salah untuk menyuntikkan kode ke dalam kernel.
  • Memasang filesystem dapat memungkinkan mounter menyebabkan beberapa file muncul sehingga ia tidak memiliki izin untuk membuatnya. Setuid eksekusi dan perangkat file adalah contoh yang paling jelas, dan mereka tetap oleh nosuiddan nodevpilihan yang tersirat dengan memiliki userdi /etc/fstab.
    Sejauh ini menegakkan userkapanmounttidak dipanggil oleh root sudah cukup. Tetapi lebih umum bisa membuat file yang dimiliki oleh pengguna lain bermasalah: konten dari file itu berisiko dikaitkan oleh pemilik yang mengaku bukan mounter. Salinan pelestarian atribut biasa dengan root ke sistem file yang berbeda akan menghasilkan file yang dimiliki oleh pemilik yang dinyatakan tetapi tidak terlibat. Beberapa program memeriksa bahwa permintaan untuk menggunakan file itu sah dengan memeriksa bahwa file tersebut dimiliki oleh pengguna tertentu, dan ini tidak lagi aman (program juga harus memeriksa bahwa direktori di jalur akses dimiliki oleh pengguna itu; jika pemasangan sewenang-wenang diizinkan, mereka juga harus memeriksa bahwa tidak ada direktori ini yang merupakan titik pemasangan di mana pemasangan dibuat bukan oleh root atau oleh pengguna yang diinginkan).

Untuk tujuan praktis, saat ini dimungkinkan untuk me-mount sistem file tanpa menjadi root, melalui FUSE . Driver FUSE dijalankan sebagai pengguna pemasangan sehingga tidak ada risiko eskalasi hak istimewa dengan mengeksploitasi bug dalam kode kernel. FUSE filesystems hanya dapat mengekspos file yang diizinkan oleh pengguna untuk dibuat, yang memecahkan masalah terakhir di atas.


24

Jika pengguna memiliki akses tulis langsung ke perangkat blok, dan dapat memasang perangkat blok itu, maka mereka dapat menulis suid yang dapat dieksekusi ke perangkat blok, me-mount, dan mengeksekusi file itu, dan dengan demikian, mendapatkan akses root ke sistem. Inilah sebabnya mengapa pemasangan biasanya dibatasi pada root.

Sekarang root dapat memungkinkan pengguna normal untuk me-mount dengan batasan tertentu, tetapi ia perlu memastikan bahwa jika pengguna memiliki akses tulis ke perangkat blok, bahwa mount tidak mengizinkan suid, dan juga devnodes, yang memiliki masalah serupa (pengguna dapat membuat devnode yang memberi mereka akses tulis ke perangkat penting yang seharusnya tidak mereka miliki akses tulisnya).


8

Itu tidak selalu membutuhkan super privs. Dariman mount

   The non-superuser mounts.
          Normally,  only  the  superuser can mount filesystems.  However,
          when fstab contains the user option on a line, anybody can mount
          the corresponding system.

          Thus, given a line

                 /dev/cdrom  /cd  iso9660  ro,user,noauto,unhide

          any  user  can  mount  the iso9660 filesystem found on his CDROM
          using the command

                 mount /dev/cdrom

          or

                 mount /cd

          For more details, see fstab(5).  Only the user  that  mounted  a
          filesystem  can unmount it again.  If any user should be able to
          unmount, then use users instead of user in the fstab line.   The
          owner option is similar to the user option, with the restriction
          that the user must be the owner of the special file. This may be
          useful e.g. for /dev/fd if a login script makes the console user
          owner of this device.  The group option  is  similar,  with  the
          restriction  that  the  user  must be member of the group of the
          special file.

Ya, Anda benar, saya sedikit tidak tepat dalam pertanyaan saya. Saya sadar bahwa seseorang dapat secara khusus diotorisasi berdasarkan mount-by-mount. Tetapi tampaknya jika titik mount dan volume keduanya dimiliki oleh pengguna maka pengguna harus dapat melakukan mount tanpa otorisasi khusus.

3
@CrazyCasta: titik mount mungkin dimiliki oleh pengguna, tetapi simpul perangkat tidak. Apa kepemilikan, dll, pada data di partisi adalah a) tidak diketahui, b) irrelevent.
goldilocks

Tetapi bagaimana jika simpul perangkat dimiliki oleh pengguna.
CrazyCasta

Maka harus ada pengecualian paralel yang dibuat di fstab, karena simpul perangkat milik pengguna akan luar biasa untuk memulai dengan (coba dan buat satu). Sekali lagi, prinsipnya adalah bahwa sistem yang aman dibatasi, dan orang-orang diberikan hak istimewa ... jika Anda belum diberikan hak istimewa, sayangnya Anda kurang beruntung. Lihat, * nix tidak menjual majalah berkapasitas tinggi di atas meja - Anda memerlukan izin.
goldilocks

Agar jelas, mount()panggilan sistem selalu membutuhkan root. utilitas suid dapat menjadi root dan memungkinkan pengguna non root untuk melakukan mount, dan jika mountperintah diinstal suid, maka ia akan melakukan ini berdasarkan pada flag pengguna di fstab. Executable suid lainnya telah ditulis untuk memungkinkan pengguna melakukan mount, seperti pmount, yang memungkinkan pengguna untuk me-mount media eksternal, dan memberlakukan batasan yang sesuai, seperti nosuid, nodev.
psusi

5

Kormac dan yang lainnya telah mengindikasikan bahwa ini bukan dilema yang Anda sajikan; menurut saya ini bermuara pada filosofi pemberian hak istimewa pengguna secara eksplisit vs. sistem di mana semua pengguna akan memiliki hak yang tidak dapat diubah untuk me-mount sistem file.

Gilles mengatasi beberapa masalah keamanan yang terkait dengan pemasangan sistem file. Saya akan secara retroaktif menghindari diskusi prolog dan tangensial tentang masalah teknis potensial yang terkait dengan hal ini (lihat komentar) tetapi saya pikir wajar jika pengguna yang tidak dipercaya tidak memiliki hak abadi untuk memasang hard drive.

Masalah yang berkaitan dengan filesystem virtual dan jarak jauh (atau filesystem jarak jauh melalui filesystem virtual, ala FUSE) kurang signifikan, tetapi ini tidak menyelesaikan pertanyaan keamanan (walaupun FUSE mungkin, dan tentu saja akan menyelesaikan masalah Anda). Penting juga untuk mempertimbangkan bahwa data dalam sistem file semacam itu hampir selalu dapat diakses tanpa perlu memasang perangkat, baik melalui transfer file atau alat yang mengekstraksi dari gambar tanpa pemasangan, sehingga sistem yang tidak memungkinkan Anda untuk me-mount sesuatu tidak tidak mewakili masalah yang tidak dapat diatasi terkait dengan mengakses data yang telah Anda tempatkan dengan aneh di file gambar, atau (lebih mudah dimengerti) ingin dapatkan dari sistem jarak jauh. Jika Anda memiliki situasi di mana ini bukan masalahnya, mungkin ada baiknya saat bertanya:

  1. Apa yang sebenarnya saya coba lakukan?

  2. Di mana saya mencoba melakukannya?

Jika administrasi sistem itu adil, maka # 2 menjelaskan mengapa # 1 tidak mungkin bagi Anda. Jika administrasi sistem tidak adil, itu politik . Solusi untuk masalah ini, "Admin sistem saya tidak adil" adalah tidak mendesain ulang OS sehingga sistem admin di mana-mana tidak dapat membatasi pengguna.

Sistem ini memungkinkan pengguna super untuk membatasi aktivitas Anda, baik secara eksplisit, atau karena kelalaian ("Kami tidak menyediakan FUSE", dll.). Keistimewaan adalah salah satu mekanisme yang dengannya hal ini tercapai. Mungkin tidak baik untuk diberitahu, "Anda tidak perlu melakukan ini," tetapi jika itu benar ... que sera ... Anda tidak perlu melakukan ini. Gunakan ftp, dll. Jika itu tidak benar, Anda harus mengganggu mereka yang bertanggung jawab.


Jawaban Anda membingungkan, bukankah volumenya sendiri (mis. / Dev / sda1, / dev / sda2, dll.) Dilindungi dari pengguna yang membaca / menulisnya? Saya bertanya-tanya mengapa pengguna tidak dapat me-mount sesuatu yang mereka dapat akses. Untuk memperjelas, jika saya memiliki file gambar yang mengatakan ext2 saya bisa menulis aplikasi yang memungkinkan saya untuk membaca / menulis dari / untuk mengatakan gambar (bukan sebagai bagian dari sistem file OS tentu saja). Aplikasi tersebut tidak akan dapat membaca / menulis dari partisi di / dev (kecuali partisi tersebut diubah untuk memungkinkan pengguna mengaksesnya, yang biasanya tidak masuk akal).
CrazyCasta

PS Saya tidak setuju bahwa pengguna harus dapat me-mount sistem file yang mereka tidak dapat mengakses tanpa otorisasi khusus karena hanya tindakan pemasangan itu berpotensi menyebabkan semacam tindakan (seperti memeriksa filesystem) yang tidak diinginkan root.
CrazyCasta

Mounting gambar masih melibatkan node perangkat (misalnya, / dev / loop). Anda benar bahwa ini membuat kerumitan, tetapi "membuat pengaturan" untuk itu akan bervariasi dari sistem ke sistem (ada pasokan perangkat loop terbatas, untuk satu hal), jadi sekali lagi, itu sebabnya secara default semuanya dibatasi. Tapi default itu masih bisa ditimpa, oleh pengguna super, atas nama siapa pun.
goldilocks

Itu poin yang bagus tentang batas simpul perangkat loop-back. Saya tidak begitu jelas mengapa perlu ada perangkat loop-kembali, sepertinya agak berlebihan. Saya tahu itu karena pemasangan memerlukan file blok-bijaksana daripada file normal. Saya tidak mengerti mengapa ini terjadi. Bisakah Anda menawarkan wawasan, seperti apakah kernel memperlakukan perangkat blok dan file biasa secara signifikan berbeda?
CrazyCasta

1
@goldilocks: Alasan jawaban ini adalah bollocks adalah karena teori Anda di balik pembatasan sangat meyakinkan, tetapi itu benar-benar salah, masalah yang Anda maksudkan tidak ada. Mengizinkan pembuatan sistem file virtual (seperti FUSE) tidak memungkinkan Anda untuk melakukan apa pun yang tidak mungkin dilakukan dengan cara yang tidak langsung menggunakan IPC. Catatan Anda tentang interupsi pada perangkat sama sekali tidak relevan; satu-satunya gangguan signifikan yang terjadi pada untuk sistem file jarak jauh berasal dari kartu jaringan, yang ditangani sepenuhnya oleh kernel.
Lie Ryan

5

FYI: Kernel terbaru memiliki dukungan "namespace". Pengguna biasa dapat membuat namespace, dan di dalam namespace itu, menjadi root dan melakukan hal-hal menyenangkan seperti me-mount sistem file.

Itu tidak memberi Anda izin super-user "nyata" - Anda hanya bisa melakukan apa yang sudah diizinkan (yaitu Anda hanya bisa memasang perangkat yang sudah bisa Anda baca).

http://lwn.net/Articles/531114/ Lihat bagian 4.


Ruang nama lebih terbatas dari itu. Anda dapat muncul rootdi dalam namespace pengguna, tetapi itu tidak memungkinkan Anda memasang tipe sistem file normal bahkan jika Anda dapat membaca & menulis perangkat blokir. Lihat percobaan 2 di sini: unix.stackexchange.com/questions/517317/…
sourcejedi

0

Karena data pada sistem file yang ingin mereka pasang mungkin membahayakan keamanan server, atau bahkan crash (jika sengaja dibuat seperti itu).


Bisakah Anda menguraikan? Saya tidak yakin bagaimana "data pada sistem file yang ingin mereka pasang" akan membahayakan keamanan. Jika Anda dapat membaca / menulis file secara normal maka Anda harus dapat me-mount-nya (adalah argumen saya). Jika saya bisa membaca / menulis titik mount maka saya harus dapat me-mount semuanya dengan pengecualian untuk benar-benar memasangnya ke direktori. Jika Anda tidak dapat membaca / menulisnya, atau tidak dapat melihat direktori yang ada untuk melihat apakah ada, maka mount akan gagal dengan cara yang sama seperti perintah ls atau cat type.

Argumen Anda valid jika 'Anda' adalah pengguna tunggal; ingat bahwa Linux (dan Unix) adalah sistem multi-pengguna, di mana pengguna belum tentu dipercaya.
sendmoreinfo

binari suid dapat ditambahkan ke perangkat, dipasang pada kotak Anda dan digunakan untuk me-root kotak, itulah sebabnya secara default ownerdan user(s)ditetapkan nosuid. Anda tidak ingin seseorang dapat memotong dengan mudah dengan membiarkan mereka menghapus secara manualnosuid
RS

@sendmoreinfo Saya sangat sadar bahwa Linux adalah sistem multi-pengguna, tidak perlu menggurui. Saya bertanya-tanya mengapa saya dilarang memasang jaringan berbagi dan file gambar yang saya punya banyak akses. jawaban kormoc mencerahkan, meskipun saya ingin tahu mengapa flag tertentu tidak dapat dipaksakan pada pengguna non-root (seperti nosuid) untuk memperbaikinya. Sepertinya saya harus bisa me-mount untuk keperluan membaca / menulis file gambar / jaringan secara sederhana yang seharusnya saya akses ke titik mount yang saya miliki.
CrazyCasta

1
@CrazyCasta WRT "membuat sistem crash", tentu saja mungkin untuk memasang perangkat keras yang rusak yang mengeksploitasi kerentanan pada antarmuka perangkat keras. Siapa pun yang memiliki hard drive dengan blok-blok buruk di dalamnya dapat memberi tahu Anda bagaimana hal itu dapat memengaruhi kernel (dan karenanya seluruh sistem) - itu akan menjadi lingkaran sibuk dan secara efektif melumpuhkan seluruh kit dan kaboodle. Agaknya ada beberapa logika pada akar dari apa yang membuatnya tidak mungkin untuk dipecahkan, karena itu adalah masalah yang sudah diketahui dan sudah ada sejak lama tanpa solusi.
goldilocks

0

Di GNOME, gvfs tidak memerlukan root untuk memasang sistem file jarak jauh (ftp atau ssh) dan gnome-mount juga tidak perlu root untuk memasang penyimpanan eksternal (drive usb, CD / DVD, dll).

Sebagian besar sistem mungkin tidak ingin memiliki seluruh GNOME hanya untuk beberapa pemasangan jarak jauh, maka Anda dapat menggunakan lufs , sshfs atau ftpfs .

gvfs, lufs, sshfs, dan ftpfs menggunakan FUSE untuk memungkinkan pengguna non-root untuk me-mount sistem file virtual; dan tidak seperti mount -o user, FUSE tidak memerlukan sysadmin untuk mengatur mount tertentu. Selama Anda memiliki hak istimewa untuk direktori mount dan sumber daya apa pun yang diperlukan untuk membangun sistem file, Anda dapat membuat mount FUSE.

Mengapa mount memerlukan hak akses root?

Karena mountterutama / awalnya ditujukan untuk sistem file lokal, yang hampir selalu melibatkan perangkat keras.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.