Bug 750869
Summary: | sudo/newrole cannot validate logins | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Josh <jokajak> | |
Component: | openssh | Assignee: | Petr Lautrbach <plautrba> | |
Status: | CLOSED CANTFIX | QA Contact: | Miroslav Vadkerti <mvadkert> | |
Severity: | urgent | Docs Contact: | ||
Priority: | urgent | |||
Version: | 6.2 | CC: | dwalsh, ebenes, eparis, ksrot, mgrepl, mmalik, mvadkert, pmoore | |
Target Milestone: | rc | Keywords: | Regression | |
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 823677 (view as bug list) | Environment: | ||
Last Closed: | 2012-05-24 10:34:41 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: | ||||
Bug Depends On: | ||||
Bug Blocks: | 805204, 823677 |
Description
Josh
2011-11-02 15:49:11 UTC
Miroslav, I just checked in fixes for this into F16 policy. b2d2ad1cd98c19dde2f90b115e599ca99025c301 Ok, I will add it. tested on RHEL6 and it works for me We missed type=AVC msg=audit(1320248434.997:315734): avc: denied { write } for pid=1017 comm="sudo" name="johndoe" dev=dm-0 ino=9831173 scontext=staff_u:staff_r:staff_sudo_t:s8:c0,c100 tcontext=system_u:object_r:faillog_t:s0 tclass=file *** Bug 751472 has been marked as a duplicate of this bug. *** A user is now able to sudo or newrole, but the fix does not seem to be complete and would require more work on the policy side. See AVCs below. This would require a respin of the policy which we want to avoid at this point. (I'm sorry for the long AVC output in this comment, but /me lazy.) Policy version: selinux-policy-3.7.19-124.el6.noarch $ ssh eal/staff_r/s8:c0,c100@mls2 Password: Last login: Wed Nov 9 04:06:44 CST 2011 from 192.168.122.1 on pts/3 Last login: Wed Nov 9 04:06:44 2011 from 192.168.122.1 [eal/staff_r/s8:c0,c100@mls2 ~]$ newrole -r sysadm_r Password: [eal/sysadm_r/s8:c0,c100@mls2 home]$ exit logout [eal/staff_r/s8:c0,c100@mls2 ~]$ sudo -i -r sysadm_r [sudo] password for eal: [root/sysadm_r/s8:c0,c100@mls2 ~]# exit exit [eal/staff_r/s8:c0,c100@mls2 ~]$ exit logout Connection to mls2 closed. ---- #============= postfix_postdrop_t ============== #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow postfix_postdrop_t postfix_spool_maildrop_t:dir write; #============= staff_sudo_t ============== #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow staff_sudo_t faillog_t:file write; #============= sysadm_t ============== #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow sysadm_t admin_home_t:file append; ---- [root/lspp_test_r/SystemLow@mls2 ~]# ausearch -m avc -ts 04:09:30 ---- time->Wed Nov 9 04:09:35 2011 type=SYSCALL msg=audit(1320833375.358:115074): arch=c000003e syscall=2 success=no exit=-13 a0=7fcb6ad2f010 a1=c2 a2=1a4 a3=8 items=0 ppid=28013 pid=28014 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=90 sgid=90 fsgid=90 tty=(none) ses=4 comm="postdrop" exe="/usr/sbin/postdrop" subj=staff_u:staff_r:postfix_postdrop_t:s8:c0,c100 key=(null) type=AVC msg=audit(1320833375.358:115074): avc: denied { write } for pid=28014 comm="postdrop" name="maildrop" dev=dm-4 ino=618 scontext=staff_u:staff_r:postfix_postdrop_t:s8:c0,c100 tcontext=system_u:object_r:postfix_spool_maildrop_t:s0 tclass=dir ---- time->Wed Nov 9 04:09:35 2011 type=SYSCALL msg=audit(1320833375.984:115082): arch=c000003e syscall=1 success=yes exit=35 a0=4 a1=7f14b115f020 a2=23 a3=20 items=0 ppid=1174 pid=28057 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1320833375.984:115082): avc: granted { setexec } for pid=28057 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=process ---- time->Wed Nov 9 04:09:35 2011 type=SYSCALL msg=audit(1320833375.989:115083): arch=c000003e syscall=1 success=yes exit=0 a0=4 a1=0 a2=0 a3=20 items=0 ppid=28057 pid=28063 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1320833375.989:115083): avc: granted { setexec } for pid=28063 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=process ---- time->Wed Nov 9 04:09:35 2011 type=SYSCALL msg=audit(1320833375.997:115084): arch=c000003e syscall=1 success=yes exit=0 a0=4 a1=0 a2=0 a3=20 items=0 ppid=28057 pid=28064 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1320833375.997:115084): avc: granted { setexec } for pid=28064 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=process ---- time->Wed Nov 9 04:09:38 2011 type=SYSCALL msg=audit(1320833378.859:115095): arch=c000003e syscall=2 success=no exit=-13 a0=7fefa7801230 a1=42 a2=180 a3=16 items=0 ppid=28073 pid=28097 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=pts3 ses=5 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s8:c0,c100 key=(null) type=AVC msg=audit(1320833378.859:115095): avc: denied { write } for pid=28097 comm="sudo" name="eal" dev=dm-4 ino=1229 scontext=staff_u:staff_r:staff_sudo_t:s8:c0,c100 tcontext=system_u:object_r:faillog_t:s0 tclass=file ---- time->Wed Nov 9 04:09:38 2011 type=SYSCALL msg=audit(1320833378.873:115102): arch=c000003e syscall=1 success=yes exit=37 a0=3 a1=7fefa77f6930 a2=25 a3=20 items=0 ppid=28097 pid=28101 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=5 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s8:c0,c100 key=(null) type=AVC msg=audit(1320833378.873:115102): avc: granted { setexec } for pid=28101 comm="sudo" scontext=staff_u:staff_r:staff_sudo_t:s8:c0,c100 tcontext=staff_u:staff_r:staff_sudo_t:s8:c0,c100 tclass=process ---- time->Wed Nov 9 04:09:36 2011 type=SYSCALL msg=audit(1320833376.004:115085): arch=c000003e syscall=1 success=yes exit=0 a0=4 a1=0 a2=0 a3=20 items=0 ppid=28057 pid=28065 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1320833376.004:115085): avc: granted { setexec } for pid=28065 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=process ---- time->Wed Nov 9 04:09:36 2011 type=SYSCALL msg=audit(1320833376.008:115086): arch=c000003e syscall=1 success=yes exit=0 a0=4 a1=0 a2=0 a3=20 items=0 ppid=28057 pid=28066 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1320833376.008:115086): avc: granted { setexec } for pid=28066 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=process ---- time->Wed Nov 9 04:09:38 2011 type=SYSCALL msg=audit(1320833378.859:115094): arch=c000003e syscall=2 success=no exit=-13 a0=7fefa7801230 a1=2 a2=180 a3=16 items=0 ppid=28073 pid=28097 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=pts3 ses=5 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s8:c0,c100 key=(null) type=AVC msg=audit(1320833378.859:115094): avc: denied { write } for pid=28097 comm="sudo" name="eal" dev=dm-4 ino=1229 scontext=staff_u:staff_r:staff_sudo_t:s8:c0,c100 tcontext=system_u:object_r:faillog_t:s0 tclass=file ---- time->Wed Nov 9 04:09:45 2011 type=SYSCALL msg=audit(1320833385.359:115103): arch=c000003e syscall=2 success=no exit=-13 a0=7fcb6ad2f010 a1=c2 a2=1a4 a3=8 items=0 ppid=28013 pid=28014 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=90 sgid=90 fsgid=90 tty=(none) ses=4 comm="postdrop" exe="/usr/sbin/postdrop" subj=staff_u:staff_r:postfix_postdrop_t:s8:c0,c100 key=(null) type=AVC msg=audit(1320833385.359:115103): avc: denied { write } for pid=28014 comm="postdrop" name="maildrop" dev=dm-4 ino=618 scontext=staff_u:staff_r:postfix_postdrop_t:s8:c0,c100 tcontext=system_u:object_r:postfix_spool_maildrop_t:s0 tclass=dir ---- time->Wed Nov 9 04:09:47 2011 type=SYSCALL msg=audit(1320833387.398:115104): arch=c000003e syscall=2 success=no exit=-13 a0=18e6a40 a1=401 a2=180 a3=14 items=0 ppid=28097 pid=28101 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=5 comm="bash" exe="/bin/bash" subj=staff_u:sysadm_r:sysadm_t:s8:c0,c100 key=(null) type=AVC msg=audit(1320833387.398:115104): avc: denied { append } for pid=28101 comm="bash" name=".bash_history" dev=dm-0 ino=33204 scontext=staff_u:sysadm_r:sysadm_t:s8:c0,c100 tcontext=system_u:object_r:admin_home_t:s0 tclass=file ---- time->Wed Nov 9 04:09:49 2011 type=SYSCALL msg=audit(1320833389.399:115109): arch=c000003e syscall=1 success=yes exit=0 a0=5 a1=0 a2=0 a3=20 items=0 ppid=1174 pid=28057 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1320833389.399:115109): avc: granted { setexec } for pid=28057 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=process strange, this should be fixed type=AVC msg=audit(1320833378.859:115094): avc: denied { write } for pid=28097 comm="sudo" name="eal" dev=dm-4 ino=1229 scontext=staff_u:staff_r:staff_sudo_t:s8:c0,c100 tcontext=system_u:object_r:faillog_t:s0 tclass=file i see this avc is fixed in the current policy. Then the question is all of these are bugs, since you are in different level. I think the main thing is you are able to log in this way. What are all these setexec denials? Most of these, which make sense to fix, should be fixed. Dan, we have some issues now (i would say because of privsep+SELinux) #============= staff_t ============== #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow staff_t sshd_t:tcp_socket write; if you try to log in with a MLS level. Of course it works with mls_socket_write_all_levels(staff_t) We probably will need to add a new MLS attribute just for this one? # rpm -q selinux-policy-mls openssh sudo selinux-policy-mls-3.7.19-153.el6.noarch openssh-5.3p1-76.el6.x86_64 sudo-1.7.4p5-8.el6.x86_64 With RHEL6.3 openssh I am unable to login: $ ssh test/staff_r/s8:c0,c100@rhel62min test/staff_r/s8:c0,c100@rhel62min's password: Connection to rhel62min closed by remote host. Connection to rhel62min closed. # ausearch -m avc -ts recent ---- time->Fri May 18 14:53:32 2012 type=SYSCALL msg=audit(1337345612.092:150): arch=c000003e syscall=1 success=no exit=-13 a0=3 a1=7fcb4b85c900 a2=30 a3=8 items=0 ppid=1367 pid=1371 auid=502 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=(none) ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=staff_u:staff_r:staff_t:s8:c0,c100 key=(null) type=AVC msg=audit(1337345612.092:150): avc: denied { write } for pid=1371 comm="sshd" path="socket:[18698]" dev=sockfs ino=18698 scontext=staff_u:staff_r:staff_t:s8:c0,c100 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=tcp_socket ---- time->Fri May 18 14:53:32 2012 type=SYSCALL msg=audit(1337345612.092:151): arch=c000003e syscall=44 success=no exit=-13 a0=4 a1=7fcb4b873660 a2=46 a3=4000 items=0 ppid=1367 pid=1371 auid=502 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=(none) ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=staff_u:staff_r:staff_t:s8:c0,c100 key=(null) type=AVC msg=audit(1337345612.092:151): avc: denied { write } for pid=1371 comm="sshd" scontext=staff_u:staff_r:staff_t:s8:c0,c100 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=unix_dgram_socket ---- time->Fri May 18 14:53:32 2012 type=SYSCALL msg=audit(1337345612.093:152): arch=c000003e syscall=1 success=no exit=-13 a0=5 a1=7fff60e71b00 a2=5 a3=1000 items=0 ppid=1367 pid=1371 auid=502 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=(none) ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=staff_u:staff_r:staff_t:s8:c0,c100 key=(null) type=AVC msg=audit(1337345612.093:152): avc: denied { write } for pid=1371 comm="sshd" path="socket:[18772]" dev=sockfs ino=18772 scontext=staff_u:staff_r:staff_t:s8:c0,c100 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=unix_stream_socket Following module fixed the problem: # cat sudomls.te policy_module(sudomls,1.0) require{ type staff_t; } mls_socket_write_all_levels(staff_t) With this module loaded I could login and switch roles using newrole and sudo: [test@rhel62min ~]$ newrole -r sysadm_r Password: [test@rhel62min ~]$ id -Z staff_u:sysadm_r:sysadm_t:s8:c0,c100 [test@rhel62min ~]$ logout [test@rhel62min ~]$ id -Z staff_u:staff_r:staff_t:s8:c0,c100 [test@rhel62min ~]$ sudo -i -r sysadm_r [sudo] password for test: [root@rhel62min ~]# id -Z staff_u:sysadm_r:sysadm_t:s8:c0,c100 [root@rhel62min ~]# exit [test@rhel62min ~]$ id -Z staff_u:staff_r:staff_t:s8:c0,c100 During the newrole/sudo execution I got this AVC: # ausearch -m avc -ts recent ---- time->Fri May 18 14:50:48 2012 type=SYSCALL msg=audit(1337345448.508:83): arch=c000003e syscall=2 success=no exit=-13 a0=2627610 a1=241 a2=180 a3=8 items=0 ppid=1310 pid=1314 auid=502 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=pts1 ses=3 comm="bash" exe="/bin/bash" subj=staff_u:sysadm_r:sysadm_t:s8:c0,c100 key=(null) type=AVC msg=audit(1337345448.508:83): avc: denied { write } for pid=1314 comm="bash" name="test" dev=vda1 ino=143732 scontext=staff_u:sysadm_r:sysadm_t:s8:c0,c100 tcontext=staff_u:object_r:user_home_dir_t:s0-s15:c0.c1023 tclass=dir I am wondering if we need sshd to set the label on the sockets to staff_u:staff_r:staff_t:s8:c0,c100 The sudo /newrole looks like a constraint violation? We definitely do not want mls_socket_write_all_levels(staff_t) We needed to add this rules because of privsep SELinux patch # sesearch -A -s staff_t -t sshd_t -c tcp_socket -p write Found 1 semantic av rules: allow userdomain sshd_t : tcp_socket { ioctl read write getattr setattr lock append bind connect listen accept getopt setopt shutdown } ; And yes, this is a constraint violation and as you said we don't want to add this one. I was just thinking about a new MLS attribute for tcp_socket. Right, I am saying the sshd should be doing a fsetfilecon(sockfd, "staff_u:staff_r:staff_t:s8:c0,c100") Which will eliminate the AVC. As well as the setcon call. The problem here is the setcon is changing the process that owns the socket to staff_u:staff_r:staff_t:s8:c0,c100 but the socket context is not being changed. So Petr just needs to pick-up a context together with a MLS range which is going to be used as well as it is done for setcon in the openssh. Yes for the unix_stream_socket, unix_dgram_socket and the tcp_socket? Karel, I think you were using old openssh, the current version is: openssh-5.3p1-81.el6. Retesting with the latest in MLS. I will report back soon. Unfortunately the latest openssh makes no difference. Logging in with other MLS range is unsuccessful: $ ssh staff/staff_r/s8:c0,c100@rhel63-mls staff/staff_r/s8:c0,c100.24.162's password: Connection to 10.34.24.162 closed by remote host. Connection to 10.34.24.162 closed. Logging in with default range is OK: $ ssh staff/staff_r@rhel63-mls staff/staff_r.24.162's password: Last login: Mon May 21 10:06:33 2012 from localhost $ logout Connection to 10.34.24.162 closed. We have no test for this scenario in openssh. But I will add a test for it. What AVC are you seeing with the latest patch? (In reply to comment #22) > Right, I am saying the sshd should be doing a > > fsetfilecon(sockfd, "staff_u:staff_r:staff_t:s8:c0,c100") > I'm trying to prepare reasonable fix of privsep patch, but this would still need selinux-policy change. sshd_t would need to be allowed to relabelfrom self, relabelto user context and also some some operations on user tcp sockets: ---- time->Mon May 21 14:35:51 2012 type=SYSCALL msg=audit(1337603751.192:1352): arch=c000003e syscall=190 success=yes exit=0 a0=3 a1=7f51967de2d9 a2=7f5198782fe0 a3=27 items=0 ppid=2934 pid=2963 auid=502 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=51 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1337603751.192:1352): avc: denied { associate } for pid=2963 comm="sshd" name="" dev=sockfs ino=30473 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem type=AVC msg=audit(1337603751.192:1352): avc: denied { relabelto } for pid=2963 comm="sshd" name="" dev=sockfs ino=30473 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=tcp_socket type=AVC msg=audit(1337603751.192:1352): avc: denied { relabelfrom } for pid=2963 comm="sshd" name="" dev=sockfs ino=30473 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=tcp_socket ---- time->Mon May 21 14:35:51 2012 type=SYSCALL msg=audit(1337603751.193:1353): arch=c000003e syscall=193 success=yes exit=39 a0=3 a1=7f51967de2d9 a2=7f51987838a0 a3=ff items=0 ppid=2934 pid=2963 auid=502 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=51 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1337603751.193:1353): avc: denied { getattr } for pid=2963 comm="sshd" name="" dev=sockfs ino=30473 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=tcp_socket There would be probably also needed changes regarding chroot_user_t context. type=AVC msg=audit(1337603751.192:1352): avc: denied { associate } for pid=2963 comm="sshd" name="" dev=sockfs ino=30473 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem type=AVC msg=audit(1337603751.192:1352): avc: denied { relabelto } for pid=2963 comm="sshd" name="" dev=sockfs ino=30473 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=tcp_socket which would be needed for all userdomains. I am getting the same AVC with a patch. But the problem is it is not working also with these rules and I am trying to figure out why. Now it looks like that also type=AVC msg=audit(1337617126.028:4936): avc: denied { write } for pid=2667 comm="sshd" path="socket:[22783]" dev=sockfs ino=22783 scontext=staff_u:staff_r:staff_t:s8:c0,c100 tcontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tclass=unix_stream_socket is in the game. Petr, I see May 21 18:23:41 localhost sshd[2785]: debug1: DEBUG: user context staff_u:staff_r:staff_t:s8:c0,c100 which rules for AVC msgs which you added. But then I get May 21 18:23:41 localhost sshd[2794]: debug1: Allocating pty. May 21 18:23:41 localhost sshd[2794]: fatal: mm_request_send: write: Permission denied May 21 18:23:41 localhost sshd[2794]: debug1: do_cleanup May 21 18:23:41 localhost sshd[2794]: fatal: mm_request_send: write: Permission denied because of the latest AVC msg I guess. I believe it can't be fixed in openssh. We should not relabel connected socket. fsetfilecon() relabels socket associated inode but not socket itself. Also relabel of connected socket could break labeled networking.[1] sshd process doesn't know which user is connecting at the time of creating socket so it can't set proper label for new socket. When user is authenticated, child sshd process changes its context to user's SELinux context. This process communicates via socket accept()ed by master sshd process, which has master's SELinux context. If the user's level is higher than sshd's then user can't write to socket and connection is closed. [1] https://bugzilla.redhat.com/show_bug.cgi?id=823677#c13 And what about the "ssh user/staff_r/s8:c0,c100@mls" syntax? Is this still a valid use case somewhere or is it "deprecated"? Is it even documented somewhere? (I can't find this use case in ssh man page ATM) You can still use this syntax but you have to use level corresponding to sshd level in order not to break MLS constraints. For your particular use case, you would be able to login if your sshd server was running with sshd_t:s8:c0,100 level. Peter can we open this bug to the Common Criteria People? I wonder what group are those people in. Anybody has an idea? Also can we unhide all the private comments. |