Weird audit2why mensagem causada pelo SELinux

3

Quando executo audit2why para ver por que há uma falha ao tentar carregar arquivos via SCP para a pasta / foo / bar em um servidor remoto que resulta em > acesso negado à pasta / foo / bar , recebo o seguinte texto:

Was caused by:
                Unknown - would be allowed by active policy
                Possible mismatch between this policy and the one 
under which the audit message was generated.

                Possible mismatch between current in-memory 
boolean settings vs. permanent ones.

Eu sei que isso está sendo causado por SELinux quando eu executo o comando:

setenforce 0

Eu posso enviar os arquivos via SCP para / foo / bar . Também digno de nota, se eu SSH entrar e cd para a pasta / foo / bar com o SELinux habilitado eu posso criar um arquivo nesta pasta.

Como eu depuraria para ver o que está causando o problema exato no SELinux?

EDITAR

Aqui está a saída de ls -lZ de / foo / bar

drwxrwx--T. root foo-users user_u:object_r:default_t:s0     bar

e a saída de uma negação de AVC de audit2allow

type=AVC msg=audit(1519304988.434:6984): avc:  denied  { write } for  pid=26506 comm="scp" name="event-20180203.log.gz" dev="dm-4" ino=7260 scontext=user_u:user_r:user_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=file
    Was caused by:
        Unknown - would be allowed by active policy
        Possible mismatch between this policy and the one under which the audit message was generated.
    
por jgr208 22.02.2018 / 16:05

1 resposta

2

o que o AVC diz:

$ echo "type=AVC msg=audit(1519304988.434:6984): avc:  denied  { write } for  pid=26506 comm="scp" name="event-20180203.log.gz" dev="dm-4" ino=7260 scontext=user_u:user_r:user_t:s0 tcontext=user_u:object_r:default_t:s0 tclass=file" |audit2allow     
#============= user_t ==============
#!!!! WARNING: 'default_t' is a base type.
allow user_t default_t:file write;

== > Um processo em execução no tipo de contexto user_t SElinux está tentando gravar em um diretório com o tipo default_t.

Alternativas para corrigir isso são:

  • reconfigure o diretório de destino para permitir que user_t escreva:

    $ sesearch -s user_t --all | grep "file. * write"

    mostrará o contexto de destino permitido para a operação de gravação de arquivos. Por exemplo, foo / bar pode ser rotulado novamente para ssh_home_t, que está na lista permitida:

    $ sudo chcon -R -t ssh_home_t / foo / bar

  • ou, se puder, altere o diretório de destino para um permitido.

  • ou crie uma nova regra usando audit2allow para ignorar o controle, mas isso abre as permissões, quebrando a meta do SELinux, portanto, deve ser a última opção. 'veja link )

por 25.02.2018 / 19:10