Bug 924466
| Summary: | SELinux is preventing /usr/bin/ssh from read, write access on the chr_file /dev/ptmx. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Garrett Holmstrom <gholms> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | dominick.grift, dwalsh, mgrepl, misc |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | abrt_hash:24d81c1ae82a5e5c73e6658edc4dd93517099195bd7b024826ac078cc7c55507 | ||
| Fixed In Version: | selinux-policy-3.11.1-103.fc18 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-09-23 00:43:42 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: | |||
Did you try to add a local policy? # grep /usr/bin/ssh /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Seems like something we could allow. I'll certainly add it to local policy if it doesn't make it into selinux-policy-targeted. ;-) We will add it. I just wanted to know if it works with the local policy for you. Oh, I see now. Grepping for /usr/bin/ssh didn't yield enough output to generate a policy, but just ssh did. The policy it generated indeed does the trick for me:
grep ssh /var/log/audit/audit.log | audit2allow -R
require {
type ssh_t;
}
#============= ssh_t ==============
term_use_ptmx(ssh_t)
Any new on this one ?
I do get :
type=AVC msg=audit(1376161805.145:2162): avc: denied { read write } for pid=14861 comm="ssh" path="/dev/ptmx" dev="devtmpfs" ino=1121 scontext=staff_u:staff_r:ssh_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ptmx_t:s0 tclass=chr_file
but I have not been able to see what create the AVC. I am also using mosh, so I guess it may be linked. I do have several AVC on ptmx, but I am not able to find what create it.
Added. selinux-policy-3.11.1-101.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-101.fc18 Package selinux-policy-3.11.1-101.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.11.1-101.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15645/selinux-policy-3.11.1-101.fc18 then log in and leave karma (feedback). selinux-policy-3.11.1-103.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-103.fc18 selinux-policy-3.11.1-103.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: I attempted to use mosh to resume a screen session on a remote system. It managed to connect and start the remote process just fine, but then it errored out, disconnected, and left me with a dangling remote process and an AVC. SELinux is preventing /usr/bin/ssh from read, write access on the chr_file /dev/ptmx. ***** Plugin leaks (86.2 confidence) suggests ****************************** If you want to ignore ssh trying to read write access the ptmx chr_file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # grep /usr/bin/ssh /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp ***** Plugin catchall (14.7 confidence) suggests *************************** If you believe that ssh should be allowed read write access on the ptmx 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: # grep ssh /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context staff_u:staff_r:ssh_t:s0-s0:c0.c1023 Target Context system_u:object_r:ptmx_t:s0 Target Objects /dev/ptmx [ chr_file ] Source ssh Source Path /usr/bin/ssh Port <Unknown> Host (removed) Source RPM Packages openssh-clients-6.1p1-6.fc18.x86_64 Target RPM Packages Policy RPM selinux-policy-3.11.1-85.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.8.3-203.fc18.x86_64 #1 SMP Mon Mar 18 12:59:28 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-03-21 13:11:23 PDT Last Seen 2013-03-21 13:11:23 PDT Local ID 347a952b-fcbf-4820-82f9-d87338c74ea3 Raw Audit Messages type=AVC msg=audit(1363896683.807:411): avc: denied { read write } for pid=2944 comm="ssh" path="/dev/ptmx" dev="devtmpfs" ino=1122 scontext=staff_u:staff_r:ssh_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ptmx_t:s0 tclass=chr_file type=AVC msg=audit(1363896683.807:411): avc: denied { read write } for pid=2944 comm="ssh" path="/dev/ptmx" dev="devtmpfs" ino=1122 scontext=staff_u:staff_r:ssh_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ptmx_t:s0 tclass=chr_file type=SYSCALL msg=audit(1363896683.807:411): arch=x86_64 syscall=execve success=yes exit=0 a0=b72050 a1=b72420 a2=b6f920 a3=50 items=0 ppid=2939 pid=2944 auid=1000 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 ses=3 tty=pts0 comm=ssh exe=/usr/bin/ssh subj=staff_u:staff_r:ssh_t:s0-s0:c0.c1023 key=(null) Hash: ssh,ssh_t,ptmx_t,chr_file,read,write audit2allow #============= ssh_t ============== allow ssh_t ptmx_t:chr_file { read write }; audit2allow -R require { type ssh_t; } #============= ssh_t ============== term_use_ptmx(ssh_t) Additional info: hashmarkername: setroubleshoot kernel: 3.8.3-203.fc18.x86_64 type: libreport