it-swarm-id.com

Menjaga rahasia dari root di Linux

Saya mencari cara untuk mengeraskan sistem linux sehingga bahkan ketika mendapatkan akses root penuh (melalui cara yang sah atau tidak sah), beberapa rahasia tetap tidak dapat diakses. Tapi pertama-tama sedikit latar belakang.

Banyak model keamanan linux yang berbeda (SELinux, TOMOYO, dll.) Berkonsentrasi pada pembatasan proses apa yang dapat dilakukan oleh kebijakan dan memastikan mereka tidak memerlukan akses root penuh. Mereka bertujuan untuk menjaga setiap eksploitasi yang terkandung sehingga bagian lain dari sistem tidak dapat dikompromikan. Namun, tampaknya ini tidak secara langsung menangani kasus di mana root lengkap telah diperoleh - atau, bahkan lebih jauh, menyimpan rahasia dari pengguna root yang valid. Tampaknya biasanya ini bisa dimatikan oleh root saat runtime.

Pendekatan lain adalah membatasi cara mendapatkan root penuh tanpa batasan - misalnya tidak mengizinkan semua akses ke pengguna root yang terhubung dari jarak jauh, tetapi membutuhkan login dari konsol fisik. Namun, ini juga bukan tujuan saya - asumsinya adalah bahwa perlindungan semacam itu telah diatasi dan akarnya sah seperti yang seharusnya.

Jelas bahwa siapa pun yang memiliki akses fisik ke mesin dapat menyimpan semua yang tersimpan di hard drive dan mungkin juga semua yang tersimpan di memori. Juga jelas bahwa jika pengguna root memiliki kekuatan untuk memodifikasi gambar biner atau kernel, tidak ada janji keamanan yang dapat diberikan setelah reboot. Saya hanya tertarik pada serangan yang dapat dilakukan tanpa me-reboot sistem.

Juga, selama proses start up, rahasia kemungkinan besar akan ditransmisikan melalui banyak tempat dan banyak fungsi penting keamanan diperlukan. Tentu saja luar biasa jika rahasia juga dapat dilindungi selama proses start up, tetapi apa yang cukup bagi saya adalah langkah selama start up di mana privilege yang lebih tinggi dapat dijatuhkan dan setelah itu tidak ada cara untuk mendapatkannya kembali.

Jadi, dengan keterbatasan ini, apa saja cara di Linux untuk mencegah pengguna root penuh mengakses beberapa rahasia?

  • Mungkinkah ada file di sistem file yang tidak dapat diakses bahkan ke root penuh dengan cara apa pun, tetapi dapat diakses oleh beberapa proses? Beberapa proses yang sedang berjalan, atau bahkan proses baru dimulai oleh proses yang saat ini memiliki akses?

  • Dapatkah rahasia disimpan dalam memori dengan menjalankan proses sehingga bahkan root penuh tidak dapat memperoleh akses kepada mereka dengan cara apa pun? Bisakah rahasia ini ditransmisikan ke proses baru dengan beberapa cara yang root tidak dapat mempengaruhi?

Ini adalah pertanyaan yang sulit untuk ditulis sehingga saya mendapatkan jawaban yang relevan dengan saya, jadi saya akan mencoba mengedit pertanyaan itu menjadi lebih spesifik jika perlu.


Hal-hal yang jelas terlintas dalam pikiran yang perlu dibatasi adalah:

  • Nonaktifkan akses ke/proc/mem

  • Nonaktifkan akses ke/proc/<pid>/mem

  • Nonaktifkan akses ke/proc/<pid>/fd/*

  • Nonaktifkan pemuatan modul (hanya setelah beberapa modul dimuat, lebih disukai)

  • Nonaktifkan akses ptrace ke proses apa pun

56
Nakedible

Sebenarnya, dimungkinkan untuk membatasi root if seseorang siap untuk mendefinisikan batasan seperti pada dasarnya mempercayai sistem operasi. Ini dapat dilakukan dengan menggunakan SELinux (yang saya tahu) dan mungkin sistem semacam itu. Contoh terbaik yang pernah saya lihat tentang SELinux yang digunakan sedemikian rupa adalah Russell Coker's Play SELinux Machine .

Sebagai gambaran umum singkat tentang cara kerjanya, nama "root" tidak spesial di Unix. UID 0 adalah. UID 0 diartikan "percaya semua yang saya katakan". Ini berlaku khusus untuk model akses standar yang digunakan pada Unix, Unixen atau bagaimana pun Anda membuat "Unix".

LSM, atau Modul Keamanan Linux, memungkinkan Anda untuk terhubung dengan apa saja dan mengaudit/menolak tindakan yang Anda inginkan. Dalam kasus SELinux, izin SELinux diperiksa setelah izin Unix, sehingga alur Anda terlihat seperti ini:

Event ----> Has Unix Permissions? ---> Has SELinux Permissions? ---> Let it happen

Tahap selanjutnya yang perlu dipahami adalah bahwa ada, atau secara historis, versi berbeda dari Kebijakan SELinux. Sebelum saya membahasnya, pahami bahwa di SELinux:

  • inode memiliki tipe, suffixed _t, yang mungkin juga disebut domain; dan
  • pengguna memiliki peran, suffixed _r.

Gabungan, mereka mengontrol tindakan apa yang mungkin dilakukan pengguna dalam peran tertentu, dan apa yang dilakukan proses dalam domain tertentu.

Sekarang, ada tiga kebijakan SELinux utama:

  1. bertarget. Ini adalah kebijakan default untuk desktop seperti Fedora. Gagasan yang ditargetkan adalah bahwa layanan sistem kritis dan daemon dijalankan dalam domain, tetapi banyak dari apa yang Anda lakukan adalah pengguna akhir dijalankan di unconfined_u:unconfined_r:unconfined_t. Tidak ada hadiah untuk menebak apa artinya - jika izin Unix berfungsi, SELinux secara efektif dilewati.
  2. ketat. Kebijakan ini mencakup penghapusan unconfined_u seluruhnya. Ini bukan proses yang mudah, terutama pada desktop Linux (mis. init 5). Secara khusus, model keamanan X11 tidak bagus dan sering membutuhkan unconfined_t untuk beberapa aplikasi. Anda dapat melakukan ini , tapi saya berharap bekerja dengan X11 menjadi lebih sulit (walaupun bukan tidak mungkin) terutama ketika menjalankan aplikasi GUI yang membutuhkan root. Ada proyek yang sedang berlangsung untuk memberikan dukungan untuk fungsionalitas seperti-SELinux di X, yang disebut XACE (X Access Control Extensions) .
  3. MLS. MLS adalah singkatan dari keamanan multi-level dan berarti akhir dari string izin: user_u:system_r:httpd_content_t.s0-s2:c5-c7, mis. angka-angka s dan c sebenarnya berarti sesuatu. Khususnya mereka membentuk tidak membaca, tidak menulis pengaturan sedemikian rupa sehingga kecuali proses berjalan pada tingkat tertentu, informasi yang mereka lihat akan terbatas. Gagasan tingkat informasi ini adalah untuk melindungi aset rahasia — SELinux pada awalnya dikembangkan oleh NSA, mungkin untuk tujuan ini.

Jadi itulah latar belakang Anda. Sekarang, menurut halaman web (lihat FAQ ) root adalah UID 0 pada mesin main; Namun, root diatur untuk dijalankan sebagai user_r dan bukan sysadm_r di ketat kebijakan. Ini berarti pengguna tidak akan diizinkan untuk menjalankan fungsi administratif dari Shell.

Yang menarik untuk diketahui adalah status dari proses lain yang membutuhkan root. Agaknya proses tersebut telah diberi label dengan tepat dan memiliki kebijakan yang memungkinkan mereka mengakses yang mereka butuhkan. Pertanyaannya kemudian menjadi bagaimana Anda mengelola sistem dan dapatkah salah satu dari proses ini meluncurkan Shell dalam konteks pengguna itu. Jika itu bisa terjadi, Anda masih bisa mengelola exploit.

Karena mesin bermain saat ini sedang down (pada saat penulisan), saya sedang mengerjakan asumsi di sini; tetapi pada dasarnya, Anda akan memerlukan proses yang berjalan di sysadm_r dan dengan UID 0 sebagai target Anda untuk dieksploitasi. Dengan asumsi proses seperti itu ada dan dapat dieksploitasi, Anda masih bisa mendapatkan root. Adapun masih bisa admin melalui root, ada dua opsi yang dapat saya pikirkan:

  • Entah ada semacam transisi tepercaya yang berarti root lalu dapat beralih ke sysadm_r (kurang aman) atau
  • Pada runlevel yang berbeda, kebijakan yang berbeda berlaku, jadi untuk admin mesin yang menetapkan runlevel ke 1 dan kebijakan tersebut tidak membatasi root. Saya menebak di sini.

Ringkasan

Jika pertanyaan Anda adalah "bisakah saya dengan mudah dan aman melakukan ini sekarang?" jawabannya adalah tidak. Jika pertanyaan Anda adalah "Saya siap belajar tentang SELinux, turun dan kotor dengan distribusi saya dan memasang cukup banyak hal yang tidak berfungsi" jawabannya adalah mungkin untuk membatasi root lebih dari instalasi rata-rata Anda. Yang mengatakan, ini tidak dengan cara apa pun membuat Anda kebal terhadap eksploitasi - itu tidak membuat tidak mungkin bagi pengguna untuk menghindari kontrol akses ekstra ini baik dalam perangkat lunak atau fisik.

Jadi ya, Anda dapat membuat hal-hal tidak terlihat oleh root; Namun, selain beban teknis, peringatan yang sama berlaku untuk pengaturan kontrol akses apa pun pada pengguna normal — tidak ada peluru perak.

Oh dan promosi diri terang-terangan: Anda mungkin suka posting blog saya di menyimpan rahasia dalam perangkat lunak . Itu ada di blog stackexchange keamanan, jadi saya tidak merasa buruk untuk mempromosikannya. Pada dasarnya, seperti yang Anda lihat, ada mekanisme untuk membuat hidup jauh lebih sulit bagi penyerang (dan Anda), tetapi pada akhirnya, ini adalah kasus "penyu-penyu" yang pada dasarnya tidak mungkin dilakukan.

33
user2213

Saya harus mengatasi masalah ini sebelumnya, ketika didekati oleh klien yang ingin menjaga 'pesan pribadi' aman antara pengguna di situs web. Dimungkinkan untuk melindungi beberapa data dalam beberapa keadaan, tetapi ini cukup terbatas.

Pendekatan saya adalah hanya menyimpan versi terenkripsi dari catatan di server, dan mengirimkannya kepada mereka (setelah dikonfirmasi tentu saja), kemudian mendekripsi sepenuhnya dari sisi klien. Ini berarti bahwa bahkan dalam hal kompromi penuh keamanan server (mis. Akses root), catatan tetap aman. Namun keterbatasan ini:

  • Data yang dilindungi hanya aman sampai titik kompromi, dan tidak lebih baru. Bergantung pada metode yang digunakan untuk mengenkripsi informasi, server yang di-root dapat menipu pengguna untuk mengungkapkan kunci dekripsi (JavaScript JavaScript, atau untuk klien GUI asli, mengeluarkan pembaruan klien yang dikompromikan) atau menyadap kunci dekripsi (jika kunci didasarkan dari metode yang sama seperti mengautentikasi pengguna, seperti kata sandi, mereka dapat dicegat selama proses otentikasi sisi-server).
  • Transmisi membutuhkan kerahasiaan ke depan yang sempurna jika tidak data terenkripsi dapat dicegat, disimpan, dan kemudian didekripsi setelah kompromi seperti dibahas di atas.
  • Ini tidak melindungi apa pun jika klien juga dikompromikan. Kecuali jika Anda memproses data terenkripsi sepenuhnya di kepala Anda sendiri (dan jika Anda bisa, Anda layak mendapatkan trofi atau sesuatu), Anda akan memberikan data sensitif kepada sesuat, dan tidak ada yang - sempurna tidak dapat dikompromikan.
  • Tidak ada cara untuk menggunakan sisi data server ini (mis. Untuk keperluan pengindeksan) kecuali metadata yang dapat didekripsi/plainteks disimpan di sampingnya, yang dapat mengungkapkan informasi tambahan.

Pada dasarnya ini membatasi potensi penggunaan untuk skenario ini, dan masih ada kelemahan, tetapi ada kemungkinan untuk bekerja dalam beberapa situasi. Pembuatan kata sandi adalah contoh sukses 'perlindungan kompromi root', di mana bahkan akses fisik tidak akan mengungkapkan kata sandi pengguna (kecuali tentu saja jika kata sandi tersebut dikirimkan pasca-kompromi).

Ada contoh lain di utas ini yang juga layak untuk dibahas, tetapi perhatikan skenario pemrosesan sisi klien, menggunakan server hanya sebagai layanan penyimpanan yang aman.

TC

14
TC Fox

Mungkinkah ada file di sistem file yang tidak dapat diakses bahkan ke root penuh dengan cara apa pun, tetapi dapat diakses oleh beberapa proses? Beberapa proses yang sedang berjalan, atau bahkan proses baru dimulai oleh proses yang saat ini memiliki akses?

Tidak. Ketika suatu proses dapat mengaksesnya, begitu pula root. Jika Anda ingin melakukan hal-hal seperti itu, Anda harus banyak memodifikasi seluruh sistem, mungkin sistem yang mem-boot kernel yang tidak dapat diubah dari beberapa perangkat yang hanya bisa dibaca dan yang menolak me-root akses file/memori tertentu sambil mengizinkannya untuk pengguna lain yang root dapat ' t berkedok.

Dapatkah rahasia disimpan dalam memori dengan menjalankan proses sehingga bahkan root penuh tidak dapat memperoleh akses kepada mereka dengan cara apa pun? Bisakah rahasia ini ditransmisikan ke proses baru dengan beberapa cara yang root tidak dapat mempengaruhi?

Tidak. Lihat jawaban di atas.

Menurut definisi, Anda tidak dapat membatasi akses untuk root. Jika Anda membatasi akses root maka itu bukan pengguna root lagi.

Jika saya ingin menolak akses root ke rahasia, maka saya akan mencoba menyembunyikannya. Wadah kriptografi, mungkin disembunyikan dalam memori swap atau di tempat lain dan hanya dapat diakses dengan kata sandi atau semacam steganografi lainnya. Sangat sulit menemukan jarum di tumpukan jerami, meskipun bukan tidak mungkin.

6
Falcon

Ada beberapa cara tidak langsung yang dengannya root dapat menjalankan kode arbitrer. Anda dapat menonaktifkannya, dan memang beberapa kerangka kerja keamanan mungkin menonaktifkannya, tetapi mereka melumpuhkan kemampuan root untuk melakukan tugas administrasi.

Sebagai contoh, root dapat membaca dan menulis ke disk secara langsung, mem-bypass segala macam izin sistem file. Anda dapat menghilangkan kemampuan ini, tetapi kemudian root tidak akan dapat memindahkan sistem file lengkap ke disk baru dalam keadaan darurat.

Root dapat memuat modul kernel, dan dengan demikian dapat melakukan semua yang dapat dilakukan kernel. Anda dapat menghilangkan kemampuan ini, tetapi kemudian Anda mencegah memuat driver untuk media hot-pluggable. (Ini mungkin diinginkan di .001% dari instalasi unix, tetapi ini bukan kasus umum.)

Root dapat memperbarui file yang dapat dieksekusi yang memungkinkan pengguna untuk masuk, seperti login atau sshd. Daemon ini menangani otentikasi pengguna, jadi jika Anda mengontrol kode mereka, Anda bisa menyuntikkan backdoor. Anda dapat menghilangkan kemampuan ini, tetapi kemudian root tidak akan dapat melakukan peningkatan keamanan.

Root dapat membuat dan menghapus pengguna dan mengubah kredensial otentikasi: jika Anda dapat mengedit /etc/passwd untuk menambahkan akun, Anda juga dapat mengeditnya untuk sementara membuat akun tanpa kata sandi. Anda dapat menghapus kemampuan ini dengan membuat beberapa file hanya-baca bahkan untuk root, tetapi kemudian Anda akan berakhir dengan sistem di mana Anda tidak dapat membuat atau menghapus akun pengguna tanpa me-reboot.

Kerangka kerja keamanan secara efektif membuat pengguna root terbatas yang hanya root di subset dari sistem - hanya root di mesin virtual, bukan di sistem "nyata". Root terbatas ini kehilangan kemungkinan melakukan tugas administrasi pada sistem yang sebenarnya. Saya pikir virtualisasi adalah yang Anda cari.

Ini relatif mudah dilakukan dengan menggunakan sistem selinux "dua kunci": root tidak memiliki izin untuk melakukan apa pun, dan beberapa pengguna lain tanpa izin root tidak, jadi untuk mengubah hal-hal, Anda harus terlebih dahulu menjadi non-root pengguna lain, maka Anda "su" untuk melakukan root untuk melakukan perubahan.

Tidak ada pengguna yang terisolasi yang dapat melakukan atau melihat apa pun.

Saya menggunakan ini. Ini bekerja dengan sangat baik.

3
cnd

Kebutuhan aktual tidak didefinisikan dengan baik dalam pertanyaan, tetapi dua solusi potensial yang disinggung belum disebutkan:

  • Wadah
  • HSM

Kontainer - yang tentu saja hanya pendekatan yang lebih masuk akal secara arsitektur terhadap apa yang sedang dilakukan sedikit demi sedikit dengan alat-alat seperti penjara dan SELinux - mungkin relevan dalam konteks pembingkaian ulang pertanyaan - apakah ada cara yang logis seperti unix-like sistem dapat terpapar ke penyerang sehingga dapat di-root-kompromi namun rahasia pada sistem fisik masih dilindungi. Dengan wadah kita semakin dekat dengan tujuan ini. Makalah baru-baru ini oleh kelompok keamanan NCC patut dibaca: https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf

HSM adalah perangkat enkripsi perangkat keras yang mencegah pengambilan kunci dekripsi melalui metode fisik atau logis, jadi mungkin jawaban untuk pertanyaan yang dibingkai ulang karena saya memiliki rahasia yang harus saya dekripsi dengan aman, apa yang harus saya lakukan dengan kunci tersebut.

2
Jonah Benton

Seperti yang dikatakan Falcon, pengguna root menurut definisi memiliki akses ke semua hal itu, atau tidak lagi menjadi pengguna root.

Kernel mengontrol semua perangkat keras, jadi setelah Anda root Anda memiliki akses yang sama. Anda benar-benar membutuhkan virtualisasi sehingga pengguna root Anda hanya root untuk OS tervirtualisasi yang sedang berjalan dan beberapa Hypervisor berada di luar itu root. (bukan untuk mengatakan bahwa hypervisors tidak dapat dieksploitasi, tetapi apa yang Anda coba lakukan adalah setara dengan ini).

2
Bradley Kreider

Sudahkah Anda mencoba Grsecurity? Itu secara efektif dapat membatasi pengguna root dalam setiap cara yang mungkin. https://grsecurity.net/

Grsecurity, ditambah dengan PaX membuat kotak Anda menjadi benteng yang tak tertembus ... jika Anda melakukannya dengan benar

2
Jauzsika