Uma maneira de desencadear uma violação da política do SELinux?

Estou estudando o funcionamento básico do SELinux e consideraria útil desencadear uma negação. Minha máquina de teste está executando o CentOS 7, é uma instalação básica do servidor sem serviços extras e a getenforce declara 'Reforçar'. Então, eu tinha certeza de que tornar o / root legível pelo mundo e tentar ler arquivos de lá como um usuário sem privilégios resolveriam o problema. Mas sem sorte! Alguém pode sugerir alguns testes rápidos? Tentando acessar caminhos, ou abrir portas, etc.

Idealmente, estou procurando comandos simples de shell que um DAC não teria restringido, mas um MAC notará e negará. Como tal, não pretendo compilar programas sob medida ou instalar serviços específicos (como um servidor Web) para conseguir isso. Isso é valioso, pois fornece uma maneira genérica e clara de ver o SELinux em ação.

Não tenho nenhum problema em modificar o DAC (ou seja, as permissões do sistema de arquivos) para torná-los menos restritivos do que seriam por padrão como parte de um teste.

Para demonstrar o utilitário do SELinux na detecção de bugs para código de terceiros / do seu próprio desenvolvedor, aqui está um teste de proteção de memória (modificando o primeiro exemplo de código aqui ):

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

Altere os booleanos para detectar o 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

Isso demonstra claramente uma política de MAC em que um DAC equivalente poderia ter sido ignorado em uma instalação básica do CentOS 7.

1. Por padrão (no CentOS no momento da gravação), sem privilégios, os usuários que não são do sistema fazem logon como a função 'unconfined_u'. No entanto, podemos mudar nosso sistema para que nosso usuário não privilegiado 'alice' seja colocado na função 'user_u'. As políticas padrão podem ser feitas para restringir claramente essa função com apenas uma pequena quantidade de configuração adicional.

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

2. Agora desative a capacidade desses usuários de executar arquivos localizados em seus diretórios pessoais e / tmp. Mais uma vez, o padrão é permitir esse comportamento. Este comando pode levar um momento para ser concluído .

   [root]# setsebool -P user_exec_content off
   

3. Agora (com nosso usuário não privilegiado), podemos fazer login e tentar executar algo em uma dessas áreas proibidas. Como você pode ver, somos negados.

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

4. Finalmente, podemos ver o log do AVC para ver nossa negação do 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 menos que você tenha alterado suas políticas na guia Boolean do system-config-selinux (ou em / etc / selinux / policy), o padrão deve responder ao seguinte (NB, você também pode instalar o setroubleshoot para um mergulho mais profundo) :

mkdir -m 755 -p / install / ks

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

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

Em seguida, reinicie o servidor da web e tente acessar http: // localhost / ks com o navegador da web. Você deve ver uma mensagem "Proibida". Se você estiver seguindo /var/log/audit/audit.logou executando ausearch -m avc -ts recent, poderá ver a mensagem: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

Você pode alterar o contexto do SELinux chcon -Rv --reference /var/www/html /install/ksse não quiser desabilitar o SELinux, mas conseguir acessar o recurso.

EDIT: desculpe, não vi que você disse "não é um servidor web". Tente chcon -u fake_u <filename>usar uma conta não privilegiada em um arquivo do sistema.

instalar dois pacotes pequenos - sem dependências

  yum install -y vsftpd lftp

iniciar um servidor FTP

  systemctl start vsftpd

crie um arquivo na casa do root

  touch ~/tux.tch

mova do diretório raiz para o diretório FTP.
nota: mova, não copie, ou o fcontext do arquivo mudará

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

efetue login no servidor FTP como usuário do cliente FTP e tente acessar o novo arquivo.
Observação: o preenchimento automático da guia não funcionará aqui

  lftp localhost
    ls pub/tux.tch
    exit

visualizar a negação nos logs brutos

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

ou se você setroubleshoot*instalou

  grep sealert /var/log/messages