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

Question

Estou estudando o funcionamento básico do SELinux e acho útil disparar uma negação. Minha máquina de teste está executando o CentOS 7, é uma instalação básica do servidor sem nenhum serviço extra e o getenforce declara 'Enforcing'. Então, tive certeza de que tornar / root legível pelo mundo e tentar ler arquivos de lá como um usuário sem privilégios faria o truque. Mas sem sorte! Alguém pode sugerir alguns testes rápidos? Tentando acessar caminhos ou abrir portas, etc.

O ideal é que eu esteja procurando por comandos de shell simples que um DAC não teria restringido, mas um MAC notará e negará. Como tal, não pretendo compilar programas personalizados ou instalar serviços específicos (como um servidor Web) para o conseguir. 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á-las menos restritivas do que seriam, por padrão, como parte de um teste.

    

Answer 1

Isso demonstra claramente uma política 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 estão logados como a função 'unconfined_u'. No entanto, podemos alterar 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 configuração adicional.

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

2. Agora desligue 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. Esse comando pode demorar um pouco para ser concluído .

   [root]# setsebool -P user_exec_content off
   

3. Agora (com nosso usuário sem privilégios), podemos fazer login e tentar executar algo em uma dessas áreas no go. Como você pode ver, nós 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 a 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
   

Answer 2

Para demonstrar a utilidade do SELinux na detecção de erros para códigos de terceiros ou do próprio desenvolvedor, aqui está uma 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;
}

Compilar e mostrar o padrão (não capturado)

$ 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

    

Answer 3

A menos que você tenha alterado suas políticas na aba booleana de system-config-selinux (ou em / etc / selinux / policy), o padrão deve responder ao seguinte (NB, você também pode querer 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 seu servidor da Web e tente acessar o link com seu navegador da Web. Você deve ver uma mensagem "Proibida". Se você estiver seguindo /var/log/audit/audit.log ou se você executar ausearch -m avc -ts recent , será possível 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 com chcon -Rv --reference /var/www/html /install/ks se 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> usando uma conta sem privilégios em um arquivo de sistema.

    

Answer 4

instale dois pacotes pequenos - sem dependências

  yum install -y vsftpd lftp

inicie um servidor FTP

  systemctl start vsftpd

crie um arquivo na casa do root

  touch ~/tux.tch

mova-se do diretório raiz para o diretório FTP.
note: move, don't copy, ou o fcontext do arquivo irá mudar

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

faça login no seu servidor FTP como usuário do cliente FTP e tente acessar o novo arquivo. Observação: a conclusão automática da guia não funcionará aqui

  lftp localhost
    ls pub/tux.tch
    exit

veja a negação nos registros brutos

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

ou se você tiver setroubleshoot* instalado

  grep sealert /var/log/messages