Un modo per innescare una violazione della politica SELinux?

Sto studiando il funzionamento di base di SELinux e troverei utile innescare un rifiuto. La mia macchina di prova esegue CentOS 7, è un'installazione server di base senza servizi aggiuntivi e getenforce afferma 'Enforcing'. Quindi ero sicuro che rendere / root leggibile in tutto il mondo e tentare di leggere i file da lì come utente non privilegiato avrebbe funzionato. Ma niente fortuna! Qualcuno può suggerire alcuni test rapidi? Cercare di accedere a percorsi o aprire porte, ecc.

Idealmente sto cercando comandi di shell semplici che un DAC non avrebbe limitato, ma un MAC noterà e negherà. In quanto tale, non sto cercando di compilare programmi su misura o installare servizi specifici (come un web-server) per raggiungere questo obiettivo. Questo è prezioso in quanto fornisce un modo generico e chiaro per vedere SELinux in azione.

Non ho alcun problema con la modifica del DAC (ovvero le autorizzazioni del filesystem) per renderle meno restrittive di quanto non lo sarebbero per impostazione predefinita come parte di un test.

Per dimostrare l'utilità di SELinux in rilevazione di bug per il codice di terze parti / il proprio sviluppatore, ecco una prova di protezione della memoria (la modifica del primo esempio di codice qui ):

#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;
}

$ 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>

Cambia booleani per cogliere il problema:

$ 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

Ciò dimostra chiaramente una politica MAC in cui un DAC equivalente avrebbe potuto essere bypassato su un'installazione base di CentOS 7.

1. Per impostazione predefinita (in CentOS al momento della scrittura), gli utenti non di sistema non privilegiati vengono registrati come ruolo 'unconfined_u'. Tuttavia, possiamo cambiare il nostro sistema in modo che il nostro utente "privilegiato" non privilegiato venga invece inserito nel ruolo "user_u". È possibile definire criteri predefiniti per limitare chiaramente questo ruolo con solo una piccola quantità di configurazione aggiuntiva.

   [root]# echo "alice:user_u:s0-s0:c0.c1023" >> /etc/selinux/targeted/seusers
   

2. Ora disattiva la possibilità per questi utenti di eseguire file che si trovano nelle loro directory home e / tmp. Ancora una volta, l'impostazione predefinita è consentire questo comportamento. Il completamento di questo comando potrebbe richiedere qualche istante .

   [root]# setsebool -P user_exec_content off
   

3. Ora (con il nostro utente senza privilegi) possiamo accedere e tentare di eseguire qualcosa su una di queste aree vietate. Come puoi vedere, ci viene negato.

   [alice]$ cp /bin/ls /tmp/
   [alice]$ /tmp/ls
   -bash: /tmp/ls: Permission denied
   

4. Infine, possiamo visualizzare il registro AVC per vedere la nostra smentita di SELinux.

   [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
   

A meno che tu non abbia modificato le tue politiche nella scheda booleana di system-config-selinux (o in / etc / selinux / policy), il default dovrebbe rispondere a quanto segue (NB, potresti anche voler installare setroubleshoot per un'immersione più profonda) :

mkdir -m 755 -p / install / ks

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

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

Quindi, riavvia il tuo server web e prova ad accedere a http: // localhost / ks con il tuo browser web. Dovresti visualizzare un messaggio "Proibito". Se stai pedinando /var/log/audit/audit.logo se corri ausearch -m avc -ts recent, allora dovresti essere in grado di vedere il messaggio: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

È quindi possibile modificare il contesto SELinux con chcon -Rv --reference /var/www/html /install/ksse non si desidera disabilitare SELinux ma si è in grado di accedere alla risorsa.

EDIT: scusa, non ho visto che hai detto "non un server web". Prova a chcon -u fake_u <filename>utilizzare un account senza privilegi in un file di sistema.

installa due piccoli pacchetti - nessuna dipendenza

  yum install -y vsftpd lftp

avviare un server FTP

  systemctl start vsftpd

crea un file nella home di root

  touch ~/tux.tch

passa dalla home di root alla directory FTP.
nota: sposta, non copiare, altrimenti cambierà il filecontesto del file

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

accedi al tuo server FTP come utente client FTP e prova ad accedere al nuovo file.
nota: il completamento automatico della scheda non funzionerà qui

  lftp localhost
    ls pub/tux.tch
    exit

visualizzare il rifiuto nei registri non elaborati

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

o se hai setroubleshoot*installato

  grep sealert /var/log/messages