> On 10/04/2010 01:03 AM, imsand@xxxxxxxxx wrote: >> Hello >> >> I'm working on SUSE SLES11SP1 and encounter the following problem. >> Setting the context of the User after ssh login doesn't work if the >> SELinux Username and the Linux Username aren't identical. >> >> -------------- >> Here is an example (SElinux User=mat_u, Linux User=mat_u): >> Oct 4 09:41:54 testsrv.example sshd[15829]: Accepted >> keyboard-interactive/pam for mat_u from 131.102.233.125 port 54714 ssh2 >> Oct 4 09:41:54 testsrv.example sshd[15829]: pam_selinux(sshd:session): >> Open Session >> Oct 4 09:41:54 testsrv.example sshd[15829]: pam_selinux(sshd:session): >> Open Session >> Oct 4 09:41:54 testsrv.example sshd[15829]: pam_selinux(sshd:session): >> Username= mat_u SELinux User = user_u Level= (null) >> Oct 4 09:41:54 testsrv.example sshd[15829]: pam_selinux(sshd:session): >> set mat_u security context to user_u:user_r:user_t >> Oct 4 09:41:54 testsrv.example sshd[15829]: pam_selinux(sshd:session): >> set mat_u key creation context to user_u:user_r:user_t >> --- >> mat_u@xxxxxxxxxxxxxxx:~> id >> uid=6575(mat_u) gid=100(users) groups=16(dialout),33(video),100(users) >> context=mat_u:staff_r:staff_t >> mat_u@xxxxxxxxxxxxxxx:~> newrole -r sysadm_r >> mat_u@xxxxxxxxxxxxxxx:~> id >> uid=6575(mat_u) gid=100(users) groups=16(dialout),33(video),100(users) >> context=mat_u:sysadm_r:sysadm_t >> -------------------- >> >> So, this is okey. The user's context after login is >> "mat_u:staff_r:staff_t" >> >> But, if the Linux User is different from the SELinux User, the default >> user's will be chosen instead. >> >> Here is the example (SELinux User=mat_u, Linux User=mat): >> --------------------- >> Oct 4 09:46:22 testsrv.example sshd[16185]: Accepted >> keyboard-interactive/pam for mat from 131.102.233.125 port 54726 ssh2 >> Oct 4 09:46:22 testsrv.example sshd[16185]: pam_selinux(sshd:session): >> Open Session >> Oct 4 09:46:22 testsrv.example sshd[16185]: pam_selinux(sshd:session): >> Open Session >> Oct 4 09:46:22 testsrv.example sshd[16185]: pam_selinux(sshd:session): >> Username= mat SELinux User = mat_u Level= (null) >> Oct 4 09:46:22 testsrv.example sshd[16185]: pam_selinux(sshd:session): >> set mat security context to mat_u:staff_r:staff_t >> Oct 4 09:46:22 testsrv.example sshd[16185]: pam_selinux(sshd:session): >> set mat key creation context to mat_u:staff_r:staff_t >> --- >> mat_u@xxxxxxxxxxxxxxx:~> id >> uid=6575(mat) gid=100(users) groups=16(dialout),33(video),100(users) >> context=user_u:user_r:user_t >> >> mat_u@xxxxxxxxxxxxxxx:~> newrole -r sysadm_r >> user_u:sysadm_r:sysadm_t is not a valid context >> --------------------- >> >> As you can see, the pam_selinux module recognizes that the new context >> should be "mat_u:staff_r:staff_t", but for some reason the real context >> is >> user_u:user_r:user_t. Changing the context with newrole doesn't work >> either... >> >> The user mappings should be okey: >> ------ >> semanage user -l | grep mat >> mat_u staff_r sysadm_r >> testsrv.example:~ # semanage login -l | grep mat >> mat >> ------- >> >> Any idea out there? Do I miss something? >> kind regards >> Matthias >> >> >> -- >> This message was distributed to subscribers of the selinux mailing list. >> If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx >> with >> the words "unsubscribe selinux" without quotes as the message. >> > > you can specify the context in > /etc/selinux/policy/contexts/users/whatroleyouused > (under sshd) I normally set user_r:user_t:s0 > > > Justin P. Mattock > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx > with > the words "unsubscribe selinux" without quotes as the message. > The file looks like: cat /etc/selinux/refpolicy/contexts/users/mat_u system_r:local_login_t staff_r:staff_t sysadm_r:sysadm_t system_r:remote_login_t staff_r:staff_t system_r:sshd_t staff_r:staff_t sysadm_r:sysadm_t system_r:crond_t staff_r:cronjob_t system_r:xdm_t staff_r:staff_t staff_r:staff_su_t staff_r:staff_t staff_r:staff_sudo_t staff_r:staff_t sysadm_r:sysadm_su_t sysadm_r:sysadm_t sysadm_r:sysadm_sudo_t sysadm_r:sysadm_t So, theoretical this should be okey, isn't it? And as you can see in the log from above (set mat key creation context to mat_u:staff_r:staff_t) it "tries" to switch to staff but for some reason it doesn't work.. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.