> On 10/07/2010 09:11 AM, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10/07/2010 10:40 AM, Chad Sellers wrote: >>> On 10/6/10 3:29 AM, "imsand@xxxxxxxxx"<imsand@xxxxxxxxx> wrote: >>> >>>>> On 10/05/2010 11:43 PM, imsand@xxxxxxxxx wrote: >>>>>>> On 10/05/2010 06:38 AM, imsand@xxxxxxxxx wrote: >>>>>>>>> On 10/04/2010 11:30 PM, imsand@xxxxxxxxx wrote: >>>>>>>>>>> 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.. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> if your sshd'ing and the context is staff_r:staff_t then it's >>>>>>>>> correct, >>>>>>>>> I >>>>>>>>> usually change this to user_r:user_t just cause I'm paranoid. >>>>>>>>> Also there is some options that you can set in /etc/pam.d to do >>>>>>>>> other >>>>>>>>> checks etc.. >>>>>>>>> >>>>>>>>> Justin P. Mattock >>>>>>>>> >>>>>>>> no it's not and that't the problem:) >>>>>>>> If I sshd'ing with mat_u it's always "user_r:user_t" even >>>>>>>> "staff_r:staff_t" is specified (see above). But it's correct if >>>>>>>> the >>>>>>>> selinux and linux users are named equaly (mat in the example). >>>>>>>> It seems that something with the context settings and usermapping >>>>>>>> isn't >>>>>>>> correct. Do you see the problem? >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Somewhere in the policy it is set to default to user_r for sshd, I >>>>>>> dont >>>>>>> think there is a boolean(but could be wrong)for that feature. maybe >>>>>>> it's >>>>>>> reading the default_contexts file which is set to use user_r:user_t >>>>>>> instead of reading mat_u for sshd(staff_r:staff_t) >>>>>>> >>>>>>> Justin P. Mattock >>>>>>> >>>>>>> >>>>>> Unfortunately I can't see a rule doing this. The curious thing is, >>>>>> that >>>>>> it >>>>>> works if the selinux user and the linux user are equivalent (both >>>>>> mat_u). >>>>>> But it does NOT work if it is mat (linux user) and mapped to mat_u >>>>>> (selinux user). >>>>>> >>>>>> >>>>> >>>>> >>>>> hmm.. something seems configured wrong, what OS are you using? do you >>>>> have semanage login/user -l set up correctly? >>>>> >>>>> over here I build the policy from git, normally edit policy/users >>>>> (add) >>>>> gen_user(name,system_u, sysadm_r staff_r user_r, s0, s0 - >>>>> mls_systemhigh, mcs_allcats) >>>>> >>>>> then after the policy is built and installed/loaded I do >>>>> semanage login -a -s name name (create name in contexts/users) >>>>> (or skip the above and just use semanage -a -s user_u name) >>>>> >>>>> seems sshd works with the given context I specify(user_r) then if I >>>>> want >>>>> to add more options I adjust /etc/pam.d/* >>>>> >>>>> Justin P. Mattock >>>>> >>>> Thanks for your reply. >>>> I'm using SLES 11 SP1. It wouldn't be the first bug regarding SELinux >>>> on >>>> this distro... ;) >>>> Here is what I've done so far. >>>> - Downloaded the latest reference policy from tresys >>>> - Compiled and installed it on my sles 11.1 >>>> - Add selinux user mat_u: "semanage user -R "staff_r system_r" -P user >>>> -a >>>> mat_u" >>>> - Add linux user mat: "useradd mat" >>>> - Set password for mat: "passwd mat" >>>> - User mapping: "semanage login -s mat_u -a mat" >>>> - add security context for mat_u by copying staff_u's context >>>> "cp /etc/selinux/refpolicy/contexts/user/staff_u >>>> /etc/selinux/refpolicy/contexts/user/mat_u" >>>> - set boolean for sysadm ssh login to true: "setsebool -P >>>> ssh_sysadm_login >>>> on" >>>> >>>> Do you know good debug options for tracing where it stucks? >>>> >>> When debugging login-type programs figuring out the context to >>> transition >>> to, there are a couple of simple useful utilities in libselinux/utils. >>> These >>> are getconlist and getdefaultcon. Most distros won't install these (as >>> they're just debugging tools), but you can build them yourself out of >>> the >>> tree. >>> >>> getconlist will print out the contexts returned by >>> get_ordered_context_list(), which are all the reachable contexts. This >>> could >>> tell you if the problem is that the context you're trying to transition >>> to >>> is for some reason unreachable. >>> >>> getdefaultcon can tell you (in verbose mode) the default seuser and >>> level >>> returned by getseuserbyname() and the default context returned by >>> get_default_context_with_rolelevel()/get_default_context_with_level(). >>> If >>> the seuser is wrong, then you know something's going wrong in >>> getseuserbyname(). >>> >>> I hope that helps. >>> >>> Thanks, >>> Chad Sellers >>> >>> >>> -- >>> 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. >>> >>> >> We ship them in fedora as selinuxconlist and selinuxdefcon >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkyt8UkACgkQrlYvE4MpobPw+wCfa8sf3A8+xhnMmdz2z3/vuJOM >> TYsAn1s18NmE9caf5MpCt312RO2Wh/BI >> =N+E/ >> -----END PGP SIGNATURE----- >> > > > o.k. I just loaded up OpenSUSE11.4, and loaded the policy(this is from > git keep in mind, not what suse offers). > after getting everything setup I was able to ssh into the machine with > my iphone, and issue id -Z.. the context I set is user_r:user_t which > the iphone showed(name:user_r:staff_t:s0) so everything is good with > this version.(not sure with 11.1, but I know 11.2 works fine, as well as > 11.4). > > 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. > Thank you for your answers. I've reinstalled the sles11.1 with the newest opensuse selinux libraries (http://download.opensuse.org/repositories/security:/SELinux/openSUSE_Factory/x86_64/), but it still struggles with the ssh login. Local login is working now! There must be a problem with pam_selinux. Here's the output of the debug log: Oct 19 16:40:50 testmachine.local sshd[7550]: pam_selinux(sshd:session): Open Session Oct 19 16:40:50 testmachine.local sshd[7550]: pam_selinux(sshd:session): Username= mat SELinux User = mat_u Level= (null) Oct 19 16:40:50 testmachine.local sshd[7550]: pam_selinux(sshd:session): set mat security context to mat_u:staff_r:insmod_t Oct 19 16:40:50 testmachine.local sshd[7550]: pam_selinux(sshd:session): set mat key creation context to mat_u:staff_r:insmod_t Oct 19 16:40:50 testmachine.local sshd[7557]: pam_unix2(sshd:setcred): pam_sm_setcred() called Oct 19 16:40:50 testmachine.local sshd[7557]: pam_unix2(sshd:setcred): username=[mat] Oct 19 16:40:50 testmachine.local sshd[7557]: pam_unix2(sshd:setcred): pam_sm_setcred: PAM_SUCCESS Oct 19 16:40:50 testmachine.local sshd[7557]: fatal: ssh_selinux_getctxbyname: Failed to get default SELinux security context for mat (in enforcing mode) Oct 19 16:40:50 testmachine.local sshd[7550]: pam_selinux(sshd:session): Close Session @justin: which policy did you installed from git? url? I tried refpolicy from tresys. -- 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.
