SELinux cria um papel personalizado

Question

Eu tenho uma pasta compartilhada via Samba e um contêiner do Docker que eu gostaria de dar acesso à dita pasta, adicionando-a como um volume para o contêiner do Docker (sim, eu sei que não é portátil).

O SELinux impede que o contêiner acesse a pasta, pois a pasta e seu conteúdo são rotulados como samba_share_t , não svirt_sandbox_file_t

Eu sei que o domínio smbd_t tem acesso a vários rótulos do SELinux (por exemplo, httpd_sys_content_t , embora sesearch -s smbd_t --allow forneça uma lista completa), mas svirt_sandbox_file_t não é um deles.

Eu vejo algumas maneiras de contornar este problema:

• Acesse o compartilhamento de samba do contêiner pela rede (o que não é desejável, já que isso exige que o samba seja instalado no contêiner e que haja sobrecarga de rede)

• Renomeie a pasta e seu conteúdo como svirt_sandbox_file_t (o que impede que o Samba acesse a pasta)

• Reconfigure a pasta e seu conteúdo como public_content_rw_t (mas isso também dá acesso a vários outros serviços que eu não quero ter acesso a essa pasta)

• Crie uma política para conceder acesso svirt_lxc_net_t ao rótulo samba_share_t (gerado por audit2allow, mas que conceda a qualquer contêiner acesso a qualquer arquivo / pasta rotulado como samba_share_t)

A outra opção que consigo pensar é criar meu próprio papel no SELinux com seu próprio rótulo, que dá acesso somente ao Samba e ao svirt (o que eu não fiz antes, mas estou disposto a tentar).

Estou sentindo falta de algo aqui? Existe uma maneira mais fácil de fazer isso?

    

Answer 1

Eu seguiria a rota de adicionar a regra para permitir que o samba escrevesse em svirt_sandbox_file_t. Já que você quer que o samba tenha permissão para enviar conteúdo para o contêiner. É samba só precisa ler o conteúdo, em seguida, basta adicionar as regras de permissão para que isso aconteça.

    

Answer 2

Você deve ser capaz de definir o booleano do SELinux apropriado, virt_sandbox_use_samba .

setsebool -P virt_sandbox_use_samba 1

    

Answer 3

No caso de alguém encontrar o mesmo problema, optei por uma solução alternativa, ou seja, permitir que smbd_t acessasse o material com o nome svirt_sandbox_file_t . Esta é uma cópia 1: 1 do samba_share_t em um sistema CentOS 7.

# cat >samba_docker_policy.te<<EOF
module samba_docker_policy 1.0;
require {
    type smbd_t;
        type svirt_sandbox_file_t;
        class dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open };
        class lnk_file { ioctl read write create getattr setattr lock append unlink link rename };
        class file { ioctl read write create getattr setattr lock append unlink link rename open };
        class filesystem { getattr quotaget };
        class fifo_file { ioctl read write create getattr setattr lock append unlink link rename open };
        class sock_file { ioctl read write create getattr setattr lock append unlink link rename open };
}

#============= svirt_sandbox_file_t ==============

allow smbd_t svirt_sandbox_file_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ;
allow smbd_t svirt_sandbox_file_t : lnk_file { ioctl read write create getattr setattr lock append unlink link rename } ;
allow smbd_t svirt_sandbox_file_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
allow smbd_t svirt_sandbox_file_t : filesystem { getattr quotaget } ;
allow smbd_t svirt_sandbox_file_t : fifo_file { ioctl read write create getattr setattr lock append unlink link rename open } ;
allow smbd_t svirt_sandbox_file_t : sock_file { ioctl read write create getattr setattr lock append unlink link rename open } ;
EOF
# checkmodule -M -m -o samba_docker_policy.mod samba_docker_policy.te
# semodule_package -o samba_docker_policy.pp -m samba_docker_policy.mod
# semodule -i samba_docker_policy.pp