-----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----- -- 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.
