Sou novo no Fedora 23 e no SELinux. Eu uso um cliente OpenVPN através do NetworkManager. Eu armazenei todos os arquivos que eu precisava do OpenVPN para acessar (certificado, CA e chave privada) dentro de ~/.cert e executei updatecon -R -v ~/.cert . No entanto, ainda estou recebendo erros de AVC do SELinux, que não permitem que o OpenVPN acesse tais arquivos. Esta é a parte relevante da saída de grep AVC /var/log/audit/audit.log | less :
type=AVC msg=audit(1457179403.296:364): avc: denied { open } for pid=2608 comm="nm-openvpn-serv" path="/home/ggoncalves/.cert/ggoncalves.key" dev="dm-2" ino=2888752 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0
type=AVC msg=audit(1457179403.296:365): avc: denied { open } for pid=2608 comm="nm-openvpn-serv" path="/home/ggoncalves/.cert/ggoncalves.key" dev="dm-2" ino=2888752 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0
type=AVC msg=audit(1457179403.330:366): avc: denied { read } for pid=2611 comm="openvpn" name="lastline-ca.crt" dev="dm-2" ino=2888749 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0
type=AVC msg=audit(1457179403.332:367): avc: denied { read } for pid=2611 comm="openvpn" name="ggoncalves.crt" dev="dm-2" ino=2888751 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0
type=AVC msg=audit(1457179403.332:368): avc: denied { read } for pid=2611 comm="openvpn" name="ggoncalves.key" dev="dm-2" ino=2888752 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0
Como eu tenho usado apenas o SELinux por alguns dias, não tenho ideia de onde começar a procurar por isso. Alguma dica?
Editar: Parece-me que o problema está no rótulo svirt_sandbox_file_t . Eu acredito que esses arquivos devem ser rotulados como home_cert_t .
Editar 2: Na verdade, todo o meu diretório pessoal foi rotulado svirt_sandbox_file_t por algum motivo. Isso é um recurso ou um bug das políticas do Docker?
Tudo bem, isso levou um tempo. Deixe-me ainda descrever a questão, no caso de alguém acabar passando pelo mesmo. Acontece que o svirt_sandbox_file_t foi atribuído pelo Docker quando montei meu diretório home como um volume com o :Z flag (conforme descrito aqui ). O Docker então aplicou recursivamente esse rótulo em todo o diretório home e, de alguma forma, não reconfigurou os rótulos FS nem aplicou restorecon funcionou.
Para restaurar minha casa para as permissões originais, eu rsync d para uma pasta temporária, excluí tudo nela e rsync de volta. Não é a ideia mais brilhante, mas funcionou. Espero que isso ajude.
O tipo de contexto de destino dos arquivos ainda está errado:
svirt_sandbox_file_t
Os arquivos em ~/.cert devem ser rotulados como home_cert_t . Experimente novamente com
restorecon -Rf ~/.cert
ou tente forçar o tipo:
chcon -t home_cert_t ~/.cert/*
É possível que haja algum bug na política selinux-policy ou no protocolo docker selinux que cause rotulagem padrão incorreta.