4

I'm new to Fedora 23 and SELinux. I use an OpenVPN client through NetworkManager. I stored all the files I needed OpenVPN to access (certificate, CA and private key) inside ~/.cert and ran updatecon -R -v ~/.cert. However, I'm still getting AVC errors from SELinux, who won't let OpenVPN access such files. This the relevant portion of the output of 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

Since I've only been using SELinux for a few days, I have no clue where to start looking for this. Any hints?

Edit: It seems to me that the problem is in the svirt_sandbox_file_t label. I believe those files should be labelled home_cert_t.

Edit 2: In fact, my whole home directory has been labeled svirt_sandbox_file_t for some reason. Is this a feature or a bug of Docker policies?

Update

Alright, this took a while. Let me further describe the issue, in case someone ends up going through the same. Turns out the svirt_sandbox_file_t had been attributed by Docker when I mounted my home directory as a volume with the :Z flag (as described here). Docker then recursively applied that label to my entire home dir, and somehow neither reconfiguring the FS labels nor applying restorecon worked.

To restore my home to the original permissions, I rsync'd it to a temporary folder, deleted everything in it and rsync'd back. Not the brightest idea, but it worked.

  • Don't mount your home directory as a Docker volume, only chosen subdirectories of the home directory. – Michael Hampton Feb 18 at 15:37
3

Target context type of the files is still wrong:

svirt_sandbox_file_t

The files in ~/.cert should be labeled as home_cert_t. Give it a try once more with

restorecon -Rf ~/.cert

or try to force the type:

chcon -t home_cert_t ~/.cert/*

It might be possible that there is some bug in selinux-policy or docker selinux policy that causes wrong default labeling.

  • Nope, still restoring to svirt_sandbox_file_t. I believe this has happened when I installed Docker... – Guilherme Mar 5 '16 at 13:02
  • Give it a try with chcon. I am not unfortunately didn't find such a bug, but I would blame docker. – Jakuje Mar 5 '16 at 13:12
  • chcon does fix it. Will this persist across reboots and FS changes? – Guilherme Mar 5 '16 at 13:17
  • Yes. It should persist over reboot, if you will not trigger relabel (or if Docker does not enforce it somehow). – Jakuje Mar 5 '16 at 13:18
  • 2
    You can achieve complete relabel during reboot by touch /.autorelabel and then rebooting system. – Jakuje Mar 5 '16 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.