chroot gagal pada OpenVPN: peraturan AppArmor atau keupayaan?

Daemon merekodkan kegagalan chroot dan profil sudah kelihatan longgar, jadi pembaikan yang menggoda ialah meluaskan peraturan laluan dan memulakan semula. Itu biasanya tidak mengubah apa-apa, kerana chroot dikawal oleh keistimewaan yang profil tidak pernah dapat menyerahkan. Untuk memutuskan lapisan mana yang perlu disentuh, tiga pemeriksaan murah diperlukan: apa yang dibenarkan dipegang oleh proses, apa yang dibenarkan oleh dasar, dan apa yang dibuang oleh pelancar sebelum kedua-duanya menjadi penting.

Dua pintu berasingan, dan hanya satu milik AppArmor

chroot memerlukan CAP_SYS_CHROOT dalam ruang nama pengguna tempat proses berjalan. Itu keistimewaan Linux lazim, diperiksa oleh kernel sebelum panggilan melakukan apa-apa dengan laluan. Secara berasingan, profil AppArmor yang menguatkuasakan boleh menolak keupayaan itu walaupun proses memilikinya, kerana dasar mandatori dirujuk bersama kelayakan dan bukan menggantikannya. Perbezaan ini penting dalam amalan: kedua-dua lapisan tinggal dalam fail berbeza dan biasanya dijaga oleh orang yang berbeza.

Kedua-dua pintu itu gagal dengan errno yang sama. Kedua-duanya menghasilkan EPERM, dan kedua-duanya muncul sebagai aduan kebenaran umum dalam log daemon, sebab itulah meneka kandungan profil membuang begitu banyak masa. Peraturan laluan yang hendak anda tambah mengawal akses fail selepas chroot berjaya; ia tidak berkaitan sama sekali dengan sama ada operasi itu dibenarkan.

Pintu ketiga terletak di atas kedua-duanya. Jika pengurus perkhidmatan atau pembalut memulakan proses tanpa keupayaan dalam set sempadannya, tiada perubahan AppArmor dapat memulihkannya, dan menambah keupayaan pada profil hanya mendokumenkan niat yang kernel tidak akan hormati.

Baca keadaan keistimewaan sebelum menyunting dasar

Mulakan daripada proses yang sedang berjalan, bukan daripada konfigurasi yang anda percaya aktif. Fail status mendedahkan lima topeng keupayaan dan bendera no-new-privileges, dan semuanya menjawab soalan yang berbeza:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff ialah set yang penting untuk panggilan: keupayaan yang ada dalam CapBnd tetapi tiada dalam CapEff dibenarkan oleh siling dan tidak dipegang sekarang. CapAmb penting apabila binari tidak berkeistimewaan dalam erti setuid biasa, kerana keupayaan ambien ialah cara perkhidmatan mengekalkan keistimewaan merentasi exec tanpa keupayaan fail. CapInh memegang bit yang boleh diwarisi merentasi exec, tetapi hanya apabila set boleh waris fail yang dilaksanakan membenarkannya, jadi satu bit di situ tidak memberikan apa-apa dengan sendirinya.

Kemudian sahkan profil mana yang benar-benar terpasang. Proses boleh terkurung oleh nama profil yang anda tidak jangkakan, terutamanya apabila sesuatu pengedaran menghantar fail unit dan profilnya bersama, dan membaca /proc/PID/attr/current menyelesaikannya dalam satu baris. Membandingkan fail yang anda sunting dengan profil yang dilaporkan kernel ialah perbezaan antara membaiki punca dan menyunting fail yang tiada siapa muat.

Tambah peraturan keupayaan hanya apabila jejak audit berkata begitu

Rekod kernel dan audit menamakan lapisan yang menolak. Cari penolakan yang membawa operasi capable dan nama sys_chroot, bersama profil yang menghasilkannya. Jika rekod itu wujud, proses sudah memegang keupayaan itu dan AppArmor menolaknya, dan perubahan yang disasarkan ialah peraturan keupayaan dalam profil sebenar:

capability sys_chroot,

Simpan ia sebagai serpihan dalam profil yang benar-benar terpasang, dan semak kata kunci terhadap rujukan profil apparmor.d dan bukan menyalin peraturan daripada tutorial yang tidak berkaitan. Memasukkannya ke dalam include kongsi memberikannya kepada setiap program terkurung yang menarik fail itu, dan menukar profil ke mod complain menyembunyikan penolakan seterusnya dan bukan menyelesaikan yang ini. Peraturan profil membuang penolakan dasar; ia tidak mencipta keistimewaan, jadi proses yang tidak pernah mempunyai CAP_SYS_CHROOT dalam set efektifnya akan tetap gagal walaupun peraturan itu ada.

Jika rekod audit tidak menunjukkan sebarang penolakan AppArmor, berhenti menyunting profil. Anda sedang melihat masalah kelayakan, dan kerja yang tinggal ada dalam fail unit atau proses induk, bukan dalam bahasa dasar.

Pengurus perkhidmatan menyimpan silingnya sendiri

systemd menetapkan set sempadan keupayaan untuk setiap perkhidmatan, dan secara lalai set itu sempit. Apa-apa yang dikecualikan di sana tidak tersedia kepada proses walau apa pun kata profil, sebab itulah unit yang dikeraskan boleh gagal dalam operasi yang berfungsi apabila daemon dimulakan dengan tangan. Arahan yang berkaitan mudah dibaca dalam unit dan mudah terlepas pandang apabila aplikasi melaporkan kegagalan. Fail drop-in yang dihantar oleh pakej pengedaran ialah sumber biasa bagi siling yang tiada siapa ingat telah dikonfigurasikan.

Menaikkan siling dan memberikan keupayaan ialah dua perubahan, bukan satu. Entri set sempadan mengatakan proses boleh memegang keupayaan itu; ia tidak menambahnya pada set efektif, dan NoNewPrivs boleh menghalang kenaikan kemudian daripada berjaya walaupun segala-galanya sepadan. Tambah hanya apa yang diperlukan oleh operasi, kekalkan pengerasan yang lain, dan tolak jalan pintas memberikan semua keupayaan supaya satu panggilan lulus.

Urutan juga penting di sini. Ubah siling unit dahulu, sahkan bahawa CapEff kini mengandungi bit itu, dan barulah tentukan sama ada AppArmor masih menolak. Melakukan kedua-dua perubahan serentak membuat anda meneka semula jika kegagalan berterusan.

Selepas penolakan hilang, periksa penjara itu sendiri

chroot yang berjaya memindahkan akar, jadi setiap laluan yang disentuh daemon selepas itu diselesaikan di dalam pokok baharu. Konfigurasi yang hilang, nod peranti yang tiada atau direktori sijil yang tidak disalin akan muncul sebagai ralat fail, dan ralat itu masalah susun atur dan bukan masalah keupayaan. Baca peristiwa seterusnya dan bukan menambah kebenaran luas yang lain. Pemindahan itu juga mengubah maksud laluan relatif, sebab itulah panduan pengerasan menuntut laluan mutlak dalam konfigurasi daemon.

Mengingat apa yang chroot tidak lakukan juga membantu. Ia sempadan laluan, bukan kotak pasir: proses yang mengekalkan keistimewaan boleh melarikan diri daripadanya, sebab itulah keupayaan biasanya dilepaskan selepas panggilan dan sebab itulah kurungan harus kekal di sekeliling daemon. Mengekalkan profil AppArmor, set sempadan keupayaan dan sekatan sistem fail bersama-sama ialah tujuan latihan ini, bukan sisa yang perlu dibuang apabila perkhidmatan bermula.

Peraturan keputusan itu ringkas. Jika rekod audit menamakan AppArmor, tambah satu peraturan keupayaan pada profil yang terpasang. Jika set efektif kosong, betulkan siling unit dan urutan pelepasan keistimewaan. Jika profil itu bukan yang anda sunting, berhenti menyunting dan cari yang sebenar.