> On 10/19/2010 07:42 AM, imsand@xxxxxxxxx wrote: >>> 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. >> >> >> >> > > > from what I remember insmod_t is a context I always received, due to > unlabeled filesystem > i.e. I also use LFS, and will tar ball the whole system, and copy it > over to the new machine, > then receive the insmod_t until I relabel, then all is good, but in your > case it shouldn't be going to that. > > > as for the policy(sounds like the same one)..: > > git clone http://oss.tresys.com/git/refpolicy.git > > in regards to sles11 im wondering if it's close to opensuse 11.1, if so > I can > load that one up on my machine to see whats happening(right now I'm kind > of floating > from one distro to the next(I have the "try that out distro itch"..)) > > Justin P. Mattock > > I don't think that opensuse 11.1 and sles 11.1 are close enough!? I found out that if the selinux user and the linux user are equal (both mat_u), the ssh login works as well. indeed insmod was gone after "make relabel", but now I can't start the system in enforcing mode anymore, because a couple of denies => most of them are related to dbus and rpc-statd: ---- avc: denied { search } for pid=2320 comm="dbus-daemon" nam e="dbus" dev=dm-7 ino=40172 scontext=system_u:system_r:sysadm_dbusd_t tcontext=system_u:object_r:system_dbusd_var_run_t tclass=dir ---- ---- avc: denied { read } for pid=3127 comm="rpc.statd" path="p ipe:[9740]" dev=pipefs ino=9740 scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t tclass=fifo_file ---- are you familiar with that? are there some booleans to set or do I have to adjust the policy? -- 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.
