+++ This bug was initially created as a clone of Bug #528040 +++ Openconnect is a VPN client. It works with HTTP authentication. First you authenticate using a certificate and/or password, and you're rewarded with an HTTP cookie. Then, you make the actual connection, using that cookie. Those two operations can be done all at once by the command line openconnect client, or it can be split into two stages. When we use the NetworkManager support, it's done in two stages -- the bit which accesses the user's certificate runs in the user's session and just passes the HTTP cookie over dbus to the nm-openconnect-service. And all is well. However, when users attempt to use the command line client manually, selinux prevents it from accessing the certificate in their home directory. The openconnect binary is switched to the vpnc_t context when it starts, and that prevents access to the user's files. What's the best way to fix this? Really, we only want openconnect to transition into the vpnc_t context _after_ the authentication has happened. Is that possible? --- Additional comment from dwalsh on 2009-10-20 16:59:46 EDT --- David didn't we have another bug where we discussed this? --- Additional comment from dwmw2 on 2009-10-21 18:23:29 EDT --- We discussed it in the review bug for openconnect, but mostly in email. --- Additional comment from dwalsh on 2009-10-22 10:59:33 EDT --- Well in Rawhide we have this mapping /home/[^/]*/\.cert(/.*)? unconfined_u:object_r:home_cert_t:s0 And allow vpnc_t home_cert_t : file { ioctl read getattr lock open } ; allow vpnc_t home_cert_t : dir { ioctl read getattr lock search open } ; allow vpnc_t home_cert_t : lnk_file { read getattr } ; Is that enough for now? --- Additional comment from dwmw2 on 2009-10-22 13:10:43 EDT --- Yes, I believe so (as discussed in IRC a week or two ago). For F-11, I'll make our certificate-downloading scripts run 'chcon -t home_cert_t -r ~/.cert' and that ought to make it work too. Thanks. --- Additional comment from mgrepl on 2010-01-06 10:36:40 EST --- Fixed in selinux-policy-3.6.12-93.fc11.noarch --- Additional comment from updates on 2010-01-08 09:30:52 EST --- selinux-policy-3.6.12-93.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/selinux-policy-3.6.12-93.fc11 --- Additional comment from updates on 2010-01-12 18:41:25 EST --- selinux-policy-3.6.12-93.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0446 --- Additional comment from updates on 2010-01-19 14:34:23 EST --- selinux-policy-3.6.12-93.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. ------------------------------------------------------------------ First of all - I think the solution has got somehow lost in Fedora 12: tkepczyn-mobl:~# semanage fcontext -l | grep -i cert /etc/certmaster(/.*)? all files system_u:object_r:certmaster_etc_rw_t:s0 /etc/cups/certs directory system_u:object_r:cupsd_rw_etc_t:s0 /etc/cups/certs/.* regular file system_u:object_r:cupsd_rw_etc_t:s0 /etc/pki(/.*)? all files system_u:object_r:cert_t:s0 /etc/pki/dovecot(/.*)? all files system_u:object_r:dovecot_cert_t:s0 /etc/racoon/certs(/.*)? all files system_u:object_r:ipsec_key_file_t:s0 /etc/rc\.d/init\.d/certmaster regular file system_u:object_r:certmaster_initrc_exec_t:s0 /etc/rc\.d/init\.d/certmonger regular file system_u:object_r:certmonger_initrc_exec_t:s0 /usr/bin/certmaster regular file system_u:object_r:certmaster_exec_t:s0 /usr/bin/certwatch regular file system_u:object_r:certwatch_exec_t:s0 /usr/lib(64)?/courier/rootcerts(/.*)? all files system_u:object_r:courier_etc_t:s0 /usr/sbin/certmonger regular file system_u:object_r:certmonger_exec_t:s0 /usr/share/ssl/certs(/.*)? all files system_u:object_r:cert_t:s0 /usr/share/ssl/certs/dovecot\.pem regular file system_u:object_r:dovecot_cert_t:s0 /usr/share/ssl/private(/.*)? all files system_u:object_r:cert_t:s0 /usr/share/ssl/private/dovecot\.pem regular file system_u:object_r:dovecot_cert_t:s0 /var/lib/certmaster(/.*)? all files system_u:object_r:certmaster_var_lib_t:s0 /var/lib/certmonger(/.*)? all files system_u:object_r:certmonger_var_lib_t:s0 /var/lib/cups/certs directory system_u:object_r:cupsd_rw_etc_t:s0 /var/lib/cups/certs/.* regular file system_u:object_r:cupsd_rw_etc_t:s0 /var/log/certmaster(/.*)? all files system_u:object_r:certmaster_var_log_t:s0 /var/named/chroot/etc/pki(/.*)? all files system_u:object_r:cert_t:s0 /var/run/certmaster.* all files system_u:object_r:certmaster_var_run_t:s0 /var/run/certmonger.pid regular file system_u:object_r:certmonger_var_run_t:s0 There is no home_cert_t type anywhere above. Second - the solution proposed in original bug will not work for root user. Third - the solution proposed in original bug will not work when home directory is nfs mounted. Fourth - I've tried to set file type with chcon as described above in /root/.cert but I am still getting: Failed to open certificate file /root/.cert/certificate.p12: Permission denied Loading certificate failed. Aborting. The problem goes away when I "setenforce 0".
# grep home_cert_t /etc/selinux/targeted/contexts/files/file_contexts.homedirs /export/home/[^/]*/\.pki(/.*)? unconfined_u:object_r:home_cert_t:s0 /export/home/[^/]*/\.cert(/.*)? unconfined_u:object_r:home_cert_t:s0 /home/[^/]*/\.pki(/.*)? unconfined_u:object_r:home_cert_t:s0 /home/[^/]*/\.cert(/.*)? unconfined_u:object_r:home_cert_t:s0 /home/devel/dwalsh/\.pki(/.*)? staff_u:object_r:home_cert_t:s0 /home/devel/dwalsh/\.cert(/.*)? staff_u:object_r:home_cert_t:s0 But we do not have a label for /root/.cert If you want to add one, # semanage fcontext -a -t home_cert_t '/root/.cert(/.*)?' # restorecon -R -v /root/.cert
David, should we have this label in the base policy?
For /root/.cert? I see no reason why not, but would normally defer to you on such matters. Certainly I see no reason why we should prevent root from being able to connect to the VPN just as any other user would... in fact that makes _most_ sense. I've always considered it entirely stupid to consider a VPN a 'per-user' thing, when it affects the networking of the _whole_ system, and every user on the system then has access to the 'private' network. Of course, if your system actually looked at users' home directories in /etc/passwd rather than making assumptions, then it would have been working for /root/.cert already. And you wouldn't need to guess at various places where sysadmins might choose to put homedirs (/export/home, etc.). You'd have '$HOME/.cert' which would expand for every home directory in the system. Might get unwieldy with NIS or LDAP user database I suppose; you'd want it only for local /etc/passwd files.
Miroslav add /root/\.cert(/.*)? gen_context(system_u:object_r:home_cert_t,s0) to userdomain.fc We treat homedirs and /root differently.
Fixed in selinux-policy-3.6.32-107.fc12
Are you going to develop a fix for home on the nfs as well?
selinux-policy-3.6.32-108.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-108.fc12
selinux-policy-3.6.32-108.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-108.fc12
Whatever you did it didn't help. I've updated and I've relabelled and it looks like files in /root/.cert have correct labels. I am still having "permission denied" thou: vesemir:~# openconnect --certificate ~/.cert/vpn/certificate.p12 --cafile ~/.cert/vpn/XXX-certchain.crt --key-password-from-fsid --script /etc/vpnc/vpnc-script --deflate --user XXXXXXX --verbose XXXXX statfs: Permission denied Attempting to connect to XXX:443 Failed to connect to host XXX Failed to open HTTPS connection to XXXX Failed to obtain WebVPN cookie I've also tried: vesemir:~# semanage permissive -a vpnc_exec_t with no luck. The only working solution is to go to permissive mode. What is troubling me more is that: # ausearch -c openconnect is not giving me any relevant messages. (the last one is from March 30th).
(In reply to comment #9) > statfs: Permission denied This is because of the --key-password-from-fsid argument. This is a silly method of tying SSL certificates to the machine, by using a passphrase automatically derived from the UUID of the file system on which they're stored (hence the statfs call for ~/.cert/vpn/). It's fairly crappy but it's as secure as the stupid 'non-exportable' but in the Windows certificate store, which was the thing we had to emulate.
OK, I know the story behind that ;). But still, selinux should be able to cope with that, it probably is missing a rule somewhere, which would allow statfs on filesystem containing ~/.cert. I also do not understand the lack of audit messages and why semanage permissive didn't help, but this is probably another bug...
selinux-policy-3.6.32-108.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
Guys, I've mentioned in #9 that it DOES NOT WORK as expected, so how could you possibly closed it?
Hi Tomasz, I apologize. The bug was automatically closed by Fedora Update System. Try the following semanage permissive -a vpnc_t
semanage permissive -a vpnc_t works but still it is more a workaround then a fix. But thanks for that, it is improvement.
ok and now are you seeing any AVC messages?
Nope. I had some, but they were becaused I ha incorrect labels on my certificate file. When I corrected labels ausearch -c openconnect reported nothing. I also saw that line: type=SYSCALL msg=audit(1271866995.490:65): arch=c000003e syscall=2 success=yes exit=4 a0=7fffac32265f a1=0 a2=1b6 a3=0 items=0 ppid=4651 pid=4652 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=2 comm="openconnect" exe="/usr/bin/openconnect" subj=unconfined_u:unconfined_r:vpnc_t:s0-s0:c0.c1023 key=(null) but I think it is related to the case were labels were incorrect.
Did you also check /var/log/messages?
Yep, nothing there as well. I am starting to wonder if I have some misconfiguration here... But on the other hand - there were some messages going to audit.log when I had incorrect labels on the certificate file. Please see comment #10 for the --key-password-from-fsid information as I use it and there is "statfs: Permission denied" as in comment #9.
There was couple policy updates. Is the bug still present?
I will have a look in the next couple of days, please bear with me.
OK, the problem is still there: vesemir:~/pliki/???# ./???-vpn2.sh statfs: Permission denied Attempting to connect to 192.55.37.76:443 Using certificate file /root/pliki/???/cert.vpn/certificate.p12 Failed to open certificate file /root/pliki/???/cert.vpn/certificate.p12: Permission denied Loading certificate failed. Aborting. Failed to open HTTPS connection to 192.55.37.76 Failed to obtain WebVPN cookie For the record: all files in directory /root/pliki/???/cert.vpn and the directory itself are security labeled as: system_u:object_r:home_cert_t:s0, selinux is enforcing and there are no permissive domains configured (except built in ones). ausearch -c openconnect does not show any messages which I can associate with the above invocation (there are other messages but the timing is so old they can be related). When selinux is in permissive mode then I can connect. When selinux is enforcing and I issue: semanage permissive -a vpnc_exec_t then I cannot connect (with the same messages as above). When selinux is enforcing and I issue: semanage permissive -a vpnc_t then I can connect. There are no messages in audit log related to openconnect after the above three tries. For the record: vesemir:~# rpm -qa openconnect selinux-\* openconnect-2.25-1.fc12.x86_64 selinux-policy-targeted-3.6.32-121.fc12.noarch selinux-policy-3.6.32-121.fc12.noarch I am still on Fedora 12 with all released updates applied.
Note that it's still the statfs() which is failing... I assume it works if you provide the passphrase manually?
I guess you suggest I remove --key-password-from-fsid from command line and when prompted for private key password I provide output from "stat -i %c /root/.cert". Tried that: vesemir:~/pliki/???# openconnect \ ? --certificate ~/pliki/???/cert.vpn/certificate.p12 \ ? --cafile ~/pliki/???/cert.vpn/???-certchain.crt \ ? --deflate \ ? --script /etc/vpnc/vpnc-script \ ? --user tomasz.kepczynski@???.com \ ? --verbose \ ? ???vpn_ip_address??? Attempting to connect to ???:443 Using certificate file /root/pliki/???/cert.vpn/certificate.p12 Failed to open certificate file /root/pliki/???/cert.vpn/certificate.p12: Permission denied Loading certificate failed. Aborting. Failed to open HTTPS connection to 192.55.37.76 Failed to obtain WebVPN cookie As you can see statfs: permission denied is gone but I still can get the connection, now it can't open the certificate file. Just to repeat - the cerificates are not in /root/.cert, they are in other directory but they are labelled to be of home_cert_t type.
Could you try to add the following local policy and test it with enforcing mode. # cat > myvpnc.te << _EOF policy_module(myvpnc, 1.0) require{ type vpnc_t; } userdom_search_admin_dir(vpnc_t) _EOF # make -f /usr/share/selinux/devel/Makefile # semodule -i myvpnc.pp Thanks.
Bingo. It works.
I think you have forgotten to update "fixed in version" because selinux-policy-3.6.32-108.fc12 definitely didn't fix it.
Oops, my fault. Fixed in selinux-policy-3.6.32-125.fc12.noarch.
selinux-policy-3.6.32-125.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/selinux-policy-3.6.32-125.fc12
selinux-policy-3.6.32-125.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.6.32-125.fc12
selinux-policy-3.6.32-125.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.