RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 750869 - sudo/newrole cannot validate logins
Summary: sudo/newrole cannot validate logins
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh
Version: 6.2
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Petr Lautrbach
QA Contact: Miroslav Vadkerti
URL:
Whiteboard:
: 751472 (view as bug list)
Depends On:
Blocks: 805204 823677
TreeView+ depends on / blocked
 
Reported: 2011-11-02 15:49 UTC by Josh
Modified: 2012-05-24 13:53 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 823677 (view as bug list)
Environment:
Last Closed: 2012-05-24 10:34:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0780 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2012-06-19 20:34:59 UTC

Description Josh 2011-11-02 15:49:11 UTC
Description of problem:
sudo and newrole cannot connect to the sssd_var_lib_t 

Version-Release number of selected component (if applicable):
3.7.19-120.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. ssh user/staff_r/s8:c0,c100@mls
2. sudo -i -r sysadm_r
3.
  
Actual results:
permission denied

Expected results:
success

Additional info:
I am able to log in to the system but I cannot newrole or sudo.

AVCs from permissive mode:
time->Wed Nov  2 11:40:34 2011
type=SYSCALL msg=audit(1320248434.989:315723): arch=c000003e syscall=55 success=yes exit=0 a0=23 a1=1 a2=11 a3=7fff9b06e390 items=0 ppid=1804 pid=1990 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sssd_nss" exe="/usr/libexec/sssd/sssd_nss" subj=system_u:system_r:sssd_t:s0-s15:c0.c1023 key=(null)
type=AVC msg=audit(1320248434.989:315723): avc:  denied  { getopt } for  pid=1990 comm="sssd_nss" path="/var/lib/sss/pipes/nss" scontext=system_u:system_r:sssd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:sssd_t:s8:c0,c100 tclass=unix_stream_socket
----
time->Wed Nov  2 11:40:34 2011
type=SYSCALL msg=audit(1320248434.989:315724): arch=c000003e syscall=45 success=yes exit=20 a0=23 a1=1a55790 a2=2200 a3=0 items=0 ppid=1804 pid=1990 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sssd_nss" exe="/usr/libexec/sssd/sssd_nss" subj=system_u:system_r:sssd_t:s0-s15:c0.c1023 key=(null)
type=AVC msg=audit(1320248434.989:315724): avc:  denied  { read } for  pid=1990 comm="sssd_nss" path="/var/lib/sss/pipes/nss" scontext=system_u:system_r:sssd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:sssd_t:s8:c0,c100 tclass=unix_stream_socket
----
time->Wed Nov  2 11:40:34 2011
type=SYSCALL msg=audit(1320248434.989:315725): arch=c000003e syscall=44 success=yes exit=20 a0=23 a1=1a5d330 a2=14 a3=0 items=0 ppid=1804 pid=1990 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sssd_nss" exe="/usr/libexec/sssd/sssd_nss" subj=system_u:system_r:sssd_t:s0-s15:c0.c1023 key=(null)
type=AVC msg=audit(1320248434.989:315725): avc:  denied  { write } for  pid=1990 comm="sssd_nss" path="/var/lib/sss/pipes/nss" scontext=system_u:system_r:sssd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:sssd_t:s8:c0,c100 tclass=unix_stream_socket
----
time->Wed Nov  2 11:40:34 2011
type=PATH msg=audit(1320248434.988:315722): item=0 name=(null) inode=9831159 dev=fd:00 mode=0140666 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:sssd_var_lib_t:s0
type=SOCKADDR msg=audit(1320248434.988:315722): saddr=01002F7661722F6C69622F7373732F70697065732F6E73730000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
type=SYSCALL msg=audit(1320248434.988:315722): arch=c000003e syscall=42 success=yes exit=0 a0=5 a1=7fff12020ea0 a2=6e a3=7fff12020b30 items=1 ppid=982 pid=1017 auid=500 uid=0 gid=502 euid=0 suid=0 fsuid=0 egid=502 sgid=502 fsgid=502 tty=pts0 ses=75 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s8:c0,c100 key=(null)
type=AVC msg=audit(1320248434.988:315722): avc:  denied  { connectto } for  pid=1017 comm="sudo" path="/var/lib/sss/pipes/nss" scontext=staff_u:staff_r:staff_sudo_t:s8:c0,c100 tcontext=system_u:system_r:sssd_t:s0-s15:c0.c1023 tclass=unix_stream_socket
type=AVC msg=audit(1320248434.988:315722): avc:  denied  { write } for  pid=1017 comm="sudo" name="nss" dev=dm-0 ino=9831159 scontext=staff_u:staff_r:staff_sudo_t:s8:c0,c100 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=sock_file
----
time->Wed Nov  2 11:40:34 2011
type=PATH msg=audit(1320248434.997:315734): item=0 name="/var/run/faillock/johndoe" inode=9831173 dev=fd:00 mode=0100600 ouid=500 ogid=0 rdev=00:00 obj=system_u:object_r:faillog_t:s0
type=CWD msg=audit(1320248434.997:315734):  cwd="/home/johndoe"
type=SYSCALL msg=audit(1320248434.997:315734): arch=c000003e syscall=2 success=yes exit=4 a0=7fec3532b4a0 a1=2 a2=180 a3=8 items=1 ppid=982 pid=1017 auid=500 uid=0 gid=502 euid=0 suid=0 fsuid=0 egid=502 sgid=502 fsgid=502 tty=pts0 ses=75 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s8:c0,c100 key=(null)
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
----
time->Wed Nov  2 11:40:36 2011
type=PATH msg=audit(1320248436.788:315740): item=0 name="/var/db/sudo/johndoe/0" inode=9831185 dev=fd:00 mode=0100600 ouid=0 ogid=502 rdev=00:00 obj=system_u:object_r:sudo_db_t:s0
type=CWD msg=audit(1320248436.788:315740):  cwd="/home/johndoe"
type=SYSCALL msg=audit(1320248436.788:315740): arch=c000003e syscall=2 success=yes exit=7 a0=7fec35320020 a1=41 a2=180 a3=0 items=1 ppid=982 pid=1017 auid=500 uid=0 gid=502 euid=0 suid=0 fsuid=0 egid=502 sgid=502 fsgid=502 tty=pts0 ses=75 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s8:c0,c100 key=(null)
type=AVC msg=audit(1320248436.788:315740): avc:  denied  { write } for  pid=1017 comm="sudo" name="0" dev=dm-0 ino=9831185 scontext=staff_u:staff_r:staff_sudo_t:s8:c0,c100 tcontext=system_u:object_r:sudo_db_t:s0 tclass=file

Comment 2 Daniel Walsh 2011-11-02 17:55:01 UTC
Miroslav, I just checked in fixes for this into F16 policy.

b2d2ad1cd98c19dde2f90b115e599ca99025c301

Comment 3 Miroslav Grepl 2011-11-02 20:49:20 UTC
Ok, I will add it.

Comment 4 Josh 2011-11-04 20:15:44 UTC
tested on RHEL6 and it works for me

Comment 5 Miroslav Grepl 2011-11-07 09:02:27 UTC
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

Comment 6 Miroslav Grepl 2011-11-07 09:03:51 UTC
*** Bug 751472 has been marked as a duplicate of this bug. ***

Comment 9 Eduard Benes 2011-11-09 10:18:01 UTC
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

Comment 10 Miroslav Grepl 2011-11-09 11:57:35 UTC
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.

Comment 12 Daniel Walsh 2011-11-09 13:20:30 UTC
What are all these setexec denials?

Comment 15 Miroslav Grepl 2012-01-26 09:20:34 UTC
Most of these, which make sense to fix, should be fixed.

Comment 17 Miroslav Grepl 2012-05-18 12:44:06 UTC
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?

Comment 18 Karel Srot 2012-05-18 12:58:28 UTC
# 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

Comment 19 Daniel Walsh 2012-05-18 18:01:00 UTC
I am wondering if we need sshd to set the label on the sockets to staff_u:staff_r:staff_t:s8:c0,c100

Comment 20 Daniel Walsh 2012-05-18 18:02:35 UTC
The sudo /newrole looks like a constraint violation?

We definitely do not want 

mls_socket_write_all_levels(staff_t)

Comment 21 Miroslav Grepl 2012-05-18 19:01:21 UTC
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.

Comment 22 Daniel Walsh 2012-05-18 19:17:58 UTC
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.

Comment 24 Miroslav Grepl 2012-05-18 19:53:37 UTC
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.

Comment 25 Daniel Walsh 2012-05-18 20:58:58 UTC
Yes for the unix_stream_socket, unix_dgram_socket and the tcp_socket?

Comment 27 Miroslav Vadkerti 2012-05-21 07:49:50 UTC
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.

Comment 28 Miroslav Vadkerti 2012-05-21 08:15:39 UTC
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.

Comment 30 Daniel Walsh 2012-05-21 13:44:22 UTC
What AVC are you seeing with the latest patch?

Comment 31 Petr Lautrbach 2012-05-21 13:49:57 UTC
(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

Comment 32 Petr Lautrbach 2012-05-21 14:16:21 UTC
There would be probably also needed changes regarding chroot_user_t context.

Comment 33 Miroslav Grepl 2012-05-21 15:55:20 UTC
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.

Comment 34 Miroslav Grepl 2012-05-21 16:20:50 UTC
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.

Comment 35 Miroslav Grepl 2012-05-21 16:26:05 UTC
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.

Comment 36 Petr Lautrbach 2012-05-24 10:34:41 UTC
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

Comment 37 Karel Srot 2012-05-24 10:56:42 UTC
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)

Comment 38 Petr Lautrbach 2012-05-24 12:58:06 UTC
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.

Comment 39 Daniel Walsh 2012-05-24 13:37:49 UTC
Peter can we open this bug to the Common Criteria People?

Comment 40 Miroslav Vadkerti 2012-05-24 13:39:32 UTC
I wonder what group are those people in. Anybody has an idea?

Comment 42 Daniel Walsh 2012-05-24 13:46:29 UTC
Also can we unhide all the private comments.


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