Bug 528040

Summary: openconnect policy problem with users' certificates
Product: [Fedora] Fedora Reporter: David Woodhouse <dwmw2>
Component: selinux-policy-targetedAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: low    
Version: 11   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 3.6.12-93.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 576991 (view as bug list) Environment:
Last Closed: 2010-01-19 19:34:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Woodhouse 2009-10-08 17:19:02 UTC
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?

Comment 1 Daniel Walsh 2009-10-20 20:59:46 UTC
David didn't we have another bug where we discussed this?

Comment 2 David Woodhouse 2009-10-21 22:23:29 UTC
We discussed it in the review bug for openconnect, but mostly in email.

Comment 3 Daniel Walsh 2009-10-22 14:59:33 UTC
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?

Comment 4 David Woodhouse 2009-10-22 17:10:43 UTC
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.

Comment 5 Miroslav Grepl 2010-01-06 15:36:40 UTC
Fixed in selinux-policy-3.6.12-93.fc11.noarch

Comment 6 Fedora Update System 2010-01-08 14:30:52 UTC
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

Comment 7 Fedora Update System 2010-01-12 23:41:25 UTC
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

Comment 8 Fedora Update System 2010-01-19 19:34:23 UTC
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.