Cara untuk memicu pelanggaran kebijakan SELinux?


12

Saya sedang mempelajari cara kerja dasar SELinux dan akan berguna untuk memicu penolakan. Mesin uji saya menjalankan CentOS 7, ini adalah penginstalan server dasar tanpa layanan tambahan, dan membuat status 'Enforcing' diberlakukan. Jadi saya merasa yakin bahwa membuat / me-root dunia dapat dibaca, dan mencoba membaca file dari sana sebagai pengguna yang tidak mampu akan melakukan triknya. Tapi tidak berhasil! Adakah yang bisa menyarankan beberapa tes cepat? Mencoba mengakses jalur, atau membuka port, dll.

Idealnya saya sedang mencari perintah shell langsung yang DAC tidak akan dibatasi, tetapi MAC akan melihat dan menolak. Karena itu saya tidak ingin mengkompilasi program yang dipesan lebih dahulu, atau menginstal layanan tertentu (seperti server web) untuk mencapai hal ini. Ini berharga karena menyediakan cara yang umum dan jelas untuk melihat SELinux dalam aksi.

Saya tidak punya masalah dengan memodifikasi DAC (yaitu izin filesystem) untuk membuatnya lebih ketat daripada standarnya sebagai bagian dari pengujian.


1
+1 mengetahui cara memicu sistem perlindungan Anda sehingga Anda dapat memverifikasi bahwa sistem itu berfungsi adalah langkah yang sangat penting dan sering terlewatkan.
gowenfawr

Saya memberikan suara untuk menutup pertanyaan ini sebagai di luar topik karena itu milik Unix & Linux SE.
Tandai

Jawaban:


3

Untuk menunjukkan utilitas SELinux dalam deteksi bug untuk pihak ketiga / kode pengembang Anda sendiri, berikut ini adalah tes perlindungan memori (memodifikasi contoh kode pertama di sini ):

#include <fcntl.h>
#include <stdio.h>
#include <sys/mman.h>

int main (void) {
  // open file read-write, get a memory-mapped pointer with private access, write permission
  int fd = open ("file_to_test", O_RDWR);
  char *p = mmap (NULL, 42, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);

  p[0] = 'a';   // put something

  // Update protection mode; SELinux response depends on sebool: allow_execmod
  int r = mprotect (p, 42, PROT_READ | PROT_EXEC);

  // Display mprotect result
  printf ("mprotect = %d\n", r);

  close(fd);
  return 0;
}
Kompilasi dan tampilkan default (tidak tertangkap)
$ echo "test data" > file_to_test
$ gcc execmod.c 

$ ./a.out 
mprotect = 0

$ sudo aureport -a

AVC Report
========================================================
# date time comm subj syscall class permission obj event
========================================================
<no events of interest were found>

Ubah booleans untuk menangkap masalah:

$ sudo getsebool allow_execmod
allow_execmod --> on

$ sudo setsebool allow_execmod 0
$ ./a.out 
mprotect = -1

$ sudo aureport -a

AVC Report
========================================================
# date time comm subj syscall class permission obj event
========================================================
1. 04/30/2015 12:26:41 a.out unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 10 file execmod unconfined_u:object_r:user_home_t:s0 denied 3612

Ini jelas berguna, dan didokumentasikan dengan baik (+1), meskipun saya bukan seorang programmer dan tidak benar-benar mengerti kodenya. Idealnya saya ingin melihat contoh nyata SELinux yang menolak upaya untuk membuka port, atau mengakses path, menggunakan alat-alat baris perintah sederhana seperti shell, netcat, telnet, dll. Saya akan mengedit pertanyaan untuk membuatnya lebih jelas.
Bijaksana

Saya harus mencari bagian kode sendiri. Saya senang Anda menambahkan tes bash di bawah ini. Saya meninggalkan kesalahan Snort dan postfix (mungkin dovecot) pada CentOS7 karena mereka paket, lebih banyak pekerjaan untuk menginstal, mungkin diperbaiki nanti dan itu hanya konfigurasi yang lebih. Jika sudah seperti itu berguna untuk praktik pembuatan kebijakan.
ǝɲǝɲbρɯͽ

3

Ini jelas menunjukkan kebijakan MAC di mana DAC setara bisa dilewati pada instalasi dasar CentOS 7.

  1. Secara default (dalam CentOS pada saat penulisan) tidak terprivasi, pengguna non-sistem masuk sebagai peran 'unconfined_u'. Namun kami dapat mengubah sistem kami sehingga 'alice' pengguna kami yang tidak diprioritaskan ditempatkan ke peran 'user_u'. Kebijakan default dapat dibuat untuk secara jelas membatasi peran ini dengan hanya sejumlah kecil konfigurasi tambahan.

    [root]# echo "alice:user_u:s0-s0:c0.c1023" >> /etc/selinux/targeted/seusers
    
  2. Sekarang nonaktifkan kemampuan pengguna ini untuk mengeksekusi file yang terletak di direktori home dan / tmp. Sekali lagi, standarnya adalah mengizinkan perilaku ini. Perintah ini mungkin perlu beberapa saat untuk diselesaikan .

    [root]# setsebool -P user_exec_content off
    
  3. Sekarang (dengan pengguna kami yang tidak berprivasi), kami dapat masuk dan mencoba untuk mengeksekusi sesuatu di salah satu dari area terlarang ini. Seperti yang Anda lihat, kami ditolak.

    [alice]$ cp /bin/ls /tmp/
    [alice]$ /tmp/ls
    -bash: /tmp/ls: Permission denied
    
  4. Akhirnya, kita dapat melihat log AVC untuk melihat penolakan SELinux kami.

    [root]# aureport -a
    
    AVC Report
    ========================================================
    # date time comm subj syscall class permission obj event
    ========================================================
    1. 02/05/15 21:08:33 bash user_u:user_r:user_t:s0 59 file execute user_u:object_r:user_tmp_t:s0 denied 693
    

Hei ya itu berhasil! Saya suka secara khusus bahwa Anda memilih pendekatan "konten exec", karena ini pasti harus ditangkap. Saya cenderung lebih suka auditd untuk mencegah penciptaan yang dapat dieksekusi di tempat pertama, tapi saya juga suka ini. Kasus penggunaan: Saya menggunakan layanan umum berbasis cloud yang membuatnya sulit untuk menginstal perangkat lunak baru (Anda harus menggunakan manajer paket mereka, dan tidak ada sudo), tetapi ada gunanya; mereka tidak memblokir pembuatan atau eksekusi dan itu adalah lingkungan pengembang ... jadi saya hanya ingin / scp paket yang saya butuhkan dan mengkompilasinya . +1
ǝɲǝɲbρɯͽ

1

Kecuali Anda telah mengubah kebijakan Anda di tab Boolean dari system-config-selinux (atau di / etc / selinux / policy), maka defaultnya akan merespons yang berikut (NB, Anda mungkin juga ingin menginstal setroubleshoot untuk menyelam lebih dalam) :

mkdir -m 755 -p / install / ks

cp /root/anaconda-ks.cfg / install / ks

chmod 644 /install/ks/anaconda-ks.cfg

Kemudian, restart server web Anda dan coba akses http: // localhost / ks dengan browser web Anda. Anda akan melihat pesan "Terlarang". Jika Anda mengikuti /var/log/audit/audit.logatau menjalankan ausearch -m avc -ts recent, maka Anda seharusnya dapat melihat pesan:type=AVC msg=audit(1391277951.222:266): avc: denied { read } for pid=1731 comm="httpd" name="ks" dev=sda1 ino=22351 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined u:object r:default t:s0 tclass=dir

Anda kemudian dapat mengubah konteks SELinux dengan chcon -Rv --reference /var/www/html /install/ksjika Anda tidak ingin menonaktifkan SELinux tetapi dapat mengakses sumber daya.

EDIT: maaf, tidak melihat Anda mengatakan "bukan server web". Coba chcon -u fake_u <filename>gunakan akun yang tidak memiliki hak pribadi pada file sistem.


Saya tidak dapat mengaktifkan saran kedua Anda (menggunakan pengguna yang baru dibuat). Saya juga lebih suka tes yang lebih umum, contoh MAC meningkatkan di mana DAC akan mengizinkannya: sedangkan ini menguji seberapa baik SELinux dapat melindungi terhadap perubahan administratif untuk pelabelan SELinux.
Bijaksana

0

instal dua paket kecil - tidak ada dependensi

  yum install -y vsftpd lftp

mulai server FTP

  systemctl start vsftpd

buat file di rumah root

  touch ~/tux.tch

pindah dari rumah root ke direktori FTP.
catatan: pindah, jangan salin, atau konteks file akan berubah

  mv ~/tux.tch /var/ftp/pub

login ke server FTP Anda sebagai pengguna klien FTP dan mencoba mengakses file baru.
catatan: tab pelengkapan otomatis tidak akan berfungsi di sini

  lftp localhost
    ls pub/tux.tch
    exit

lihat penolakan di log mentah

  grep AVC /var/log/audit/audit.log

atau jika Anda telah setroubleshoot*menginstal

  grep sealert /var/log/messages
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.