Description of problem: Problem: Creating SSH VPN connections and turning them on in GNOME Settings w/ SELinux is ENFORCING mode gets block by SELinux. * I count 40 SELinux AVC denials when I performed iniated the connection in PERMISSIVE mode Steps to reproduce: 1. Open GNOME Settings 2. Navigate to the Network settings 3. Click on the "+" icon next to "VPN" to add a VPN connection 4. Add an SSH VPN connection (just change the "Gateway" parameter to the IP of any box w/ sshd running) 5. Turn the VPN connection on * This was done w/ SELinux in PERMISSIVE mode * The SSH server serving as the gateway needs the "PermitTunnel" sshd option set to "yes" Expected result: Connection to VPN succeeds while SELinux is set to ENFORCING mode SELinux is preventing sshpass from 'open' accesses on the chr_file /dev/pts/1. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that sshpass should be allowed open access on the 1 chr_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'sshpass' --raw | audit2allow -M my-sshpass # semodule -X 300 -i my-sshpass.pp Additional Information: Source Context system_u:system_r:NetworkManager_ssh_t:s0 Target Context system_u:object_r:devpts_t:s0 Target Objects /dev/pts/1 [ chr_file ] Source sshpass Source Path sshpass Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-283.30.fc27.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.15.14-300.fc27.x86_64 #1 SMP Thu Mar 29 16:13:44 UTC 2018 x86_64 x86_64 Alert Count 2 First Seen 2018-04-10 18:19:00 EDT Last Seen 2018-04-10 18:21:53 EDT Local ID 3bfa4838-de46-40ad-b9bd-d96111489166 Raw Audit Messages type=AVC msg=audit(1523398913.811:549): avc: denied { open } for pid=5718 comm="sshpass" path="/dev/pts/1" dev="devpts" ino=4 scontext=system_u:system_r:NetworkManager_ssh_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file permissive=1 Hash: sshpass,NetworkManager_ssh_t,devpts_t,chr_file,open Version-Release number of selected component: selinux-policy-3.13.1-283.30.fc27.noarch Additional info: component: selinux-policy reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.15.14-300.fc27.x86_64 type: libreport
Created attachment 1420114 [details] File: screencast-04-10-2018-06:42:46 PM.webm
selinux-policy-3.13.1-283.32.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d3085b9774
I'm up to date as of April 16, and still experiencing the issue. I do have some custom policy modules generated by SELinux Troubleshooter in effect. I'm not sure how to flush them out and reset my policy to stock without a full OS reload. Could you help me out with that?
selinux-policy-3.13.1-283.32.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d3085b9774
In case anyone else experiences this issue, it seems as though getting the text out of /var/log/audit/audit.log and piping it into audit2allow generates a policy module that remedies the issue. The annoying part is that SELinux Troubleshooter (the GUI thing) doesn't report certain AVC denials, so you need to do it via the terminal. Make sure to run through the scenario while SELinux is in Permissive mode before attempting to use audit2allow.
selinux-policy-3.13.1-283.32.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.