SELinux me-reset kata sandi root

Penafian: Pertanyaan ini bukan untuk menyelesaikan masalah mengubah kata sandi root saat SELinux aktif karena sudah ada banyak panduan untuk menyelesaikannya. Ini lebih dari bagaimana SELinux melakukan itu secara internal.

Saya pengguna SELinux baru-baru ini tetapi belakangan ini saya lebih banyak berhubungan dengannya. Ada saat ketika seseorang bertanya kepada saya bagaimana saya bisa mengatur ulang kata sandi root jika lupa.

Jadi saya mem-boot CentOS saya, mengedit entri grub ke sesuatu seperti

linux16 <kernel_location> root=/dev/mapper/centos-root rw init=/bin/bash

Saya berlari passwddan kemudian berlari syncdan memaksa reboot. Setelah reboot, masuk dengan kata sandi baru ditolak juga seperti yang lama.

Reboot lagi dan memberikan kernel parameter untuk menonaktifkan SELinux ( selinux=0). Mencoba masuk dengan kata sandi baru dan berhasil. Setelah itu saya memaksa relabel otomatis fs (melalui file .autorelabel) dan dengan SELinux aktif sekarang mungkin untuk masuk.

Pertanyaan saya adalah: mengapa itu terjadi? Mengapa relabeling mempengaruhi login ketika hanya ada perubahan kata sandi dan bukan pengguna atau objek?

Terima kasih atas perhatian Anda.

TL; DR: Reset kata sandi root biasa tidak berfungsi di SELinux. Mengapa?

Sunting: Ini diuji pada mesin virtual yang menjalankan CentOS7 dengan KVM sebagai hypervisor.

— Jorge Heleno
sumber

Apakah Anda yakin itu tidak berhasil? Coba lagi. Mungkin akan bekerja dengan baik. Saya menduga Anda hanya memiliki konteks file yang salah pada beberapa file, menyebabkan semua login gagal. Jadi autorelabel adalah yang benar-benar memperbaiki masalah.

— Michael Hampton

@MichaelHampton Saya baru saja menelusuri semua langkah saya melakukannya lagi dan tidak bisa masuk lagi dengan SELinux aktif. Setelah menonaktifkannya saya bisa masuk tanpa masalah. Perbaiki saya jika saya salah, tetapi mengubah kata sandi tidak boleh mengubah konteks file, bukan?

— Jorge Heleno

Tidak seharusnya tidak. Anda sepertinya telah menemukan sesuatu yang aneh dan tidak terduga.

— Michael Hampton

Saya dapat menduplikasi masalah ini dalam sistem CentOS 7.5 yang baru diinstal.

Inilah yang terjadi:

Saat Anda boot dengan init=/bin/bashada dua masalah yang mungkin Anda temui:

Sistem file root dapat di-mount hanya baca. Dalam hal ini passwdakan mengeluh tentang Authentication token manipulation error.

Ini cukup jelas: Jika sistem file tidak di-mount baca-tulis, tidak mungkin untuk menulis ke sana.
Kebijakan SELinux mungkin tidak dimuat. Dalam hal ini passwdakan berhasil mengubah kata sandi, tetapi Anda akan memiliki masalah yang dijelaskan dalam pertanyaan awal di atas: tidak ada yang bisa masuk.

Hash kata sandi disimpan dalam /etc/shadowfile. File ini biasanya memiliki tipe SELinux shadow_t. Namun, mengubah file sementara tidak ada kebijakan SELinux yang dimuat menyebabkan tipe SELinux dihapus dari file, meninggalkannya sebagai unlabeled_t. Dengan demikian, layanan yang mencoba membaca file untuk mengotentikasi login tidak lagi dapat membacanya.

Untuk mengubah kata sandi root di RHEL / CentOS 7, Anda harus mengikuti proses ini:

Tambahkan init=/bin/bashke akhir baris perintah kernel di grub, seperti yang Anda lakukan sebelumnya.
Di bash prompt, muat kebijakan SELinux dengan /usr/sbin/load_policy -i.
Pasang root filesystem read-write mount -o remount,rw /.
Sekarang ubah kata sandi, dan itu akan berhasil. passwd root
Remount sistem file hanya baca untuk melakukan perubahan dan memiliki sistem file bersih pada boot berikutnya dengan mount -o remount,ro /.
Keluar dari shell atau restart sistem dengan exec /sbin/init 6.

Sekarang Anda dapat masuk dengan kata sandi root yang diubah.

Sebuah penjelasan yang lebih panjang dari prosedur ini tersedia dari Red Hat (berlangganan diperlukan).

— Michael Hampton
sumber

Masalahnya ada pada kebijakan yang tidak dimuat. Mengapa mereka tidak dimuat? SELinux harus beroperasi pada level kernel sehingga sistem init seharusnya tidak diperlukan.

— Jorge Heleno

@JorgeHeleno SELinux memang hidup atau mati secara default ketika kernel dimulai, tetapi userland bertanggung jawab untuk memutuskan kebijakan mana yang dimuat. Kernel tidak dapat memutuskan hal ini, karena beberapa instalasi mungkin menginginkan kebijakan yang berbeda (mis. Ditargetkan, ketat, ml). Ini terjadi pada awal proses boot, tetapi Anda mem-bypassnya saat dijalankan init=/bin/bash.

— Michael Hampton

jika suatu kebijakan tidak dimuat mengapa passwd"tampaknya berhasil"?

— Andrew Savinykh

dan jika tidak berhasil, mengapa login dengan kata sandi lama masih gagal?

— Lightness Races dalam Orbit

@ Jorge Helen: Penjelasan Anda hampir selesai. Intinya adalah file yang diubah oleh passwdyaitu /etc/passwddan /etc/shadow. Jika berjalan passwdtanpa kebijakan yang dimuat, itu tidak berjalan dalam konteks selinux yang tepat, dan file yang diubah berakhir dengan konteks selinux yang berbeda. Ketika booting dengan selinux diaktifkan, dan kebijakan aktif pemeriksaan kata sandi gagal karena konteks file yang tidak pantas, dan bukan karena wrong passwordkesalahan. Memaksa selinux ke kontekstual fil yang /.autorelabeldapat dinyalakan dengan menyentuh juga dapat memperbaiki masalah tersebut saat mengubah kata sandi tanpa kebijakan yang dimuat.

— hargut