Bug 1565851 - SELinux is preventing sshpass from 'open' accesses on the chr_file /dev/pts/1. (+ more)
Summary: SELinux is preventing sshpass from 'open' accesses on the chr_file /dev/pts/1...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 27
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:cad1b15f3cd0c382bbd80f47b45...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-10 22:52 UTC by Claude Léveillé
Modified: 2018-04-27 01:18 UTC (History)
5 users (show)

Fixed In Version: selinux-policy-3.13.1-283.32.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-27 01:18:53 UTC
Type: ---


Attachments (Terms of Use)
File: screencast-04-10-2018-06:42:46 PM.webm (357.79 KB, application/octet-stream)
2018-04-10 22:52 UTC, Claude Léveillé
no flags Details

Description Claude Léveillé 2018-04-10 22:52:32 UTC
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

Comment 1 Claude Léveillé 2018-04-10 22:52:39 UTC
Created attachment 1420114 [details]
File: screencast-04-10-2018-06:42:46 PM.webm

Comment 2 Fedora Update System 2018-04-16 11:33:55 UTC
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

Comment 3 Claude Léveillé 2018-04-16 23:28:03 UTC
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?

Comment 4 Fedora Update System 2018-04-18 02:59:49 UTC
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

Comment 5 Claude Léveillé 2018-04-18 22:06:04 UTC
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.

Comment 6 Fedora Update System 2018-04-27 01:18:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.