A maneira mais segura / segura de permitir que o script de propriedade / raiz acesse o arquivo em / root sob selinux

Question

Eu tenho um mapa baseado no programa autofs que eu escrevi, que monta automaticamente os compartilhamentos CIFS, recebendo credenciais de um arquivo que está localizado na pasta ~/.smb de qualquer usuário. Pode haver vários arquivos de credenciais, em que cada nome de arquivo corresponde ao nome do domínio do servidor CIFS de destino.

As montagens de autofs são executadas por automounter(8) , que é definido como um serviço systemd na minha compilação do Centos 7. O automounter é executado como root, o script de mapa do autofs é de propriedade de root e é definido como permissões de 0700, e há um arquivo de credencial que está em /root/.smb com 0600 perms. Por direito, eu teria pensado que o automounter deveria ser capaz de ler o arquivo de credenciais.

Isto é, até que o SELinux fique no caminho; Em seguida, ele registra em audit.log (linebreaks adicionados para facilitar a leitura):

type=AVC msg=audit(1508458225.901:143): avc:  
    denied  { read } for  
    pid=4786 
    comm="auto.smb-user" 
    name="mydomain.credentials" 
    dev="sda1" 
    ino=10180973 
    scontext=system_u:system_r:automount_t:s0
    tcontext=unconfined_u:object_r:admin_home_t:s0 
    tclass=file

O processo do automount é executado corretamente com setenforce 0 , é claro, mas eu prefiro me acostumar com o SELinux do que desativá-lo o tempo todo

Acho que esse registro de auditoria significa que meu script auto.smb-user não pode acessar mydomain.credentials porque o arquivo está marcado como admin_home_t e os processos marcados com automount_t não podem acessá-los?

Em primeiro lugar, estou lendo isso certo? Se não, qual a melhor forma de interpretar?

Em segundo lugar, como se pode adicionar uma exceção mínima do SELinux, de modo que este script possa acessar qualquer arquivo de credencial sob ~/.smb , para qualquer usuário, inclusive o root (preferencialmente somente se for executado por automount); que sobrevive a reinicialização, yum update , etc.?

    

Answer 1

Sim - você está lendo a saída corretamente.

O contexto de origem é automount_t e o contexto de destino é admin_home_t , e é negado porque automount_t não tem permissão de leitura em admin_home_t .

Para verificar isso, você pode usar o seguinte comando:

sesearch -d -A -s autmount_t -t admin_home_t

E você notará que ele retorna uma linha vazia - o que significa que automount_t não tem permissões em admin_home_t .

Agora você tem duas opções:

• Alterando o contexto de arquivo do arquivo para automount_var_run_t , que é uma solução mais fácil e mais simples, que faz o SELinux pensar que o arquivo é de propriedade do automount, permitindo praticamente tudo, incluindo leitura e gravação (no entanto tenha em mente que o resultado efetivo ainda pode ser substituído por permissões de arquivos normais ou ACLs!)
• Adicionando um pacote de políticas, que é uma solução mais abrangente e insana, pois concederá automount_t de acesso de leitura a admin_home_t , ... mas fornecerá apenas acesso de leitura a ele, em oposição a " proprietário "acesso.
• (Há uma terceira opção também, combinando os dois anteriores e complicando-os um pouco mais - criando seu próprio tipo de contexto, aplicando-o a esses arquivos e, em seguida, criando um módulo de política que permita que automount_t acesse esse tipo. Eu não vou entrar em detalhes sobre isso.

Alterando o contexto do arquivo para automount_var_run_t

Esta é a opção mais fácil e envolve simplesmente a alteração do filecontexto do arquivo /root/.smb to automount_var_run_t - assim, qualquer processo em execução com o tipo automount_t poderá acessá-lo. Neste caso, no entanto, também terá outras permissões. Verificar sesearch -d -A -s autmount_t -c file dirá qual:

allow automount_t automount_var_run_t : file { ioctl read write getattr lock add_name remove_name search open } ;

Se você está bem com o automount tendo essas permissões nesses arquivos, você pode ir em frente e realmente mudar o contexto do arquivo para automount_var_run_t, faça o seguinte:

semanage fcontext -a -t automount_var_run_t "/root/.smb"
restorecon /root/.smb

Isso deve habilitar o automount para acessar o arquivo para o root. Agora, para adicionar acesso para todos os outros usuários (supondo que eles tenham a localização inicial padrão, ...) faça o seguinte:

semanage fcontext -a -t autmount_var_run_t "/home/(.*)+/.smb"
restorecon -R /home

Isso deve permitir que o autmount funcione como você descreveu.

Dando permissão automount_t para ler admin_home_t

Isso dará a permissão automount_t para ler os arquivos all com o contexto admin_home_t. Provavelmente não é realmente o que você quer - mas por uma questão de perfeição

Obtenha as linhas relevantes de audit.log e coloque-as em um arquivo, por exemplo automount-audit.log . Em seguida, execute o seguinte:

audit2allow -i automount-audit.log -m automount > automount-audit.te

Isso gerará um arquivo de imposição de tipo a partir da linha do log de auditoria, e será algo como isto:

module automount-smb 1.0;

require {
    type admin_home_t;
    type automount_t;
    class file read;
}

#============== autmount_t ==============
allow automount_t admin_home_t:file read;

Se você também quiser permitir acesso a user_home_t (para usuários normais e não-root), adicione a seguinte linha ao final:

allow automount_t user_home_t:file read;

Então você precisa compilar o módulo com:

checkmodule -M -m -o automount-smb.mod automount-smb.te

Crie o pacote de políticas no módulo:

semodule_package -o automount-smb.pp -m automount-smb.mod

E finalmente (whew!) insira o pacote de políticas no kernel:

semodule -i automount-smb.pp

Isso agora deve permitir processos com o rótulo automount_t acesso de leitura a todos os arquivos com o contexto admin_home_t ou user_home_t .