> On 10/20/2010 07:25 AM, imsand@xxxxxxxxx wrote: >>> On 10/20/2010 01:42 AM, imsand@xxxxxxxxx wrote: >>>>> On 10/19/2010 08:47 AM, imsand@xxxxxxxxx wrote: >>>>>>> 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? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>>> from what I remember opensuse 11.2 had issues starting due too >>>>> /etc/selinux/config having the wrong permissions(should be >>>>> -rw-r--r--.) >>>> the permissions were already correct on my system. >>>> >>> >>> cool... opensuse 11.2 was wrong(should be fixed now), causing SELinux >>> to >>> always look for targeted >>> >>>>> has issues with /etc/initscript causing SELinux to not >>>>> transition(thread >>>>> here)..: >>>>> http://oss.tresys.com/pipermail/refpolicy/2010-February/002012.html >>>>> >>>>> for some reason sysvinit craps out with: >>>>> if (access(INITSCRIPT, R_OK) == 0&& runlevel != 'S') { >>>>> >>>>> I played around with sysvinit, but my code skills only took me so >>>>> far: >>>>> http://www.spinics.net/lists/selinux/msg08983.html >>>>> >>>>> two solutions to this is too mv /etc/initscript{,-bak} or >>>>> setsebool -P init_upstart on >>>>> this way you transistion properly and you wont receive a dbus >>>>> error(if >>>>> this is whats happening with sles11.1) >>>> You're right. after setting init_upstart=1 I don't receive a dbus >>>> error >>>> anymore. >>>> >>> >>> the biggest issue is sles11.1 doesn't even use upstart.. this is caused >>> by >>> /etc/initscript (just having that file present, causes things to go out >>> of whack) >>> >>>>> >>>>> thirdly login context gets the wrong role.. simple fix is on this >>>>> report: >>>>> https://bugzilla.novell.com/show_bug.cgi?id=582366 >>>>> >>>>> here are the bug reports that got fixed so opensuse 11.2 is able to >>>>> get >>>>> up and running in full enforcement mode. >>>>> >>>>> https://bugzilla.novell.com/show_bug.cgi?id=581505 >>>>> https://bugzilla.novell.com/show_bug.cgi?id=582399 >>>>> https://bugzilla.novell.com/show_bug.cgi?id=582404 >>>>> >>>>> hopefully these are similar to what you're hitting...this way you can >>>>> get up and running properly... >>>>> >>>> I was gone through all reports but so far I have an other problem >>>> preventing me from logging in (in enforcing mode). >>>> "Permissions on the password database may be too restrictive." => >>>> I'm >>>> sure >>>> that the password is correct. >>>> >>> >>> cool... you might need to make enableaudit or semodule -DB to show more >>> avc's being denied >>> >>>> This could be related to pam stuff (like described in aboves bugs), >>>> but >>>> first of all I would like to get rid of some other problems: >>>> type=AVC msg=audit(1287563356.696:342): avc: denied { module_request >>>> } >>>> for pid=3839 comm="sshd" scontext=system_u:system_r:sshd_t >>>> tcontext=system_u:system_r:kernel_t tclass=system >>>> type=AVC msg=audit(1287563356.848:343): avc: denied { search } for >>>> pid=3839 comm="sshd" name="root" dev=dm-2 ino=7828 >>>> scontext=system_u:system_r:sshd_t tcontext=system_u:object_r:default_t >>>> tclass=dir >>>> type=AVC msg=audit(1287563360.848:344): avc: denied { module_request >>>> } >>>> for pid=3839 comm="sshd" scontext=system_u:system_r:sshd_t >>>> tcontext=system_u:system_r:kernel_t tclass=system >>>> type=AVC msg=audit(1287563360.904:345): avc: denied { search } for >>>> pid=3848 comm="sshd" name="root" dev=dm-2 ino=7828 >>>> scontext=system_u:system_r:sshd_t tcontext=system_u:object_r:default_t >>>> tclass=dir >>>> type=AVC msg=audit(1287563361.056:346): avc: denied { search } for >>>> pid=3849 comm="xauth" name="root" dev=dm-2 ino=7828 >>>> scontext=root:staff_r:xauth_t tcontext=system_u:object_r:default_t >>>> tclass=dir >>>> type=AVC msg=audit(1287563361.056:347): avc: denied { write } for >>>> pid=3849 comm="xauth" name="root" dev=dm-2 ino=7828 >>>> scontext=root:staff_r:xauth_t tcontext=system_u:object_r:default_t >>>> tclass=dir >>>> >>>> Do you see what the problem could be? >>>> >>> >>> copy/pasting and using audit2allow -i file gets me nothing(format must >>> be messd up or something), anyways dan is saying something about root >>> in >>> there name="root" so looking into what he had suggested is what >>> probably >>> needs to be done.. >>> over here ls -lZ /root shows >>> system_u:object_r:default_t:s0 >>> >>> >>> >>>> >>>> And there is another issue which prevents syslogd from starting: >>>> >>>> Oct 20 09:21:20 testmachine.local syslog-ng[3103]: Error opening file >>>> for >>>> writing; filename='/dev/tty10', error='Permission denied (13)' >>>> Oct 20 09:21:20 testmachine.local syslog-ng[3103]: Error opening file >>>> for >>>> writing; filename='/dev/xconsole', error='Permission denied (13)' >>>> >>>> Any ideas? >>>> >>> >>> thats a new one to me.. my guess is the file labels are wrong, >>> i.e. ubuntu had an issue a few yrs ago, to where /var/log/* >>> need to have restorecond -R /var done every-time at startup in order >>> for >>> the system to load into enforcement mode(with selinux-policy-default) >>> but is fixed now. >>> >>> 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. >>> >> >> >> okey, here are some more infos regarding the login process: >> ---- >> type=AVC msg=audit(1287584199.835:407448): avc: denied { read } for >> pid=3850 comm="sshd" name="shadow" dev=dm-2 >> ino=48107 scontext=system_u:system_r:sshd_t >> tcontext=system_u:object_r:shadow_t tclass=file >> type=AVC msg=audit(1287584199.835:407449): avc: denied { open } for >> pid=3850 comm="sshd" name="shadow" dev=dm-2 >> ino=48107 scontext=system_u:system_r:sshd_t >> tcontext=system_u:object_r:shadow_t tclass=file >> type=AVC msg=audit(1287584199.835:407450): avc: denied { getattr } for >> pid=3850 comm="sshd" path="/etc/shadow" d >> ev=dm-2 ino=48107 scontext=system_u:system_r:sshd_t >> tcontext=system_u:object_r:shadow_t tclass=file >> ---- >> seems that sshd isn't able to access /etc/shadow. shouldn't that be >> allowed by default?? >> The /root context looks like this: > > I think I misunderstood what dan was talking about by posting the > context of /root (but could be wrong).. I think whats wrong here is > /etc/shadow you should be seeing avc's with chkpwd_exec_t which > pam_selinux.so is responsible for doing > > when you login(after xdm/gdm) whats id -Z look like? > over here I have name:staff_r:staff_t:s0 > >> --- >> drwx------+ 6 root root system_u:object_r:default_t 4096 >> 2010-10-20 >> 16:23 root >> --- >> --- >> drwx------+ 6 root root system_u:object_r:default_t 4096 2010-10-20 >> 16:23 . >> drwxr-xr-x+ 24 root root system_u:object_r:root_t 4096 2010-10-20 >> 16:14 .. >> -rw-------+ 1 root root system_u:object_r:default_t 7133 2010-10-20 >> 16:13 .bash_history >> drwxr-xr-x+ 2 root root system_u:object_r:default_t 4096 2010-05-05 >> 16:04 bin >> -rw-r--r--+ 1 root root system_u:object_r:default_t 40014 2010-10-07 >> 09:38 cobbler_autoyast.xml >> -rw-r--r--+ 1 root root system_u:object_r:default_t 1332 2005-11-23 >> 17:06 .exrc >> -rw-r-----+ 1 root root system_u:object_r:default_t 4 2010-10-07 >> 10:15 .forward >> drwx------+ 2 root root system_u:object_r:default_t 4096 2010-10-07 >> 10:44 .gnupg >> drwxr-xr-x+ 5 root root system_u:object_r:default_t 4096 2010-10-07 >> 09:20 inst-sys >> drwxr-xr-x+ 2 root root system_u:object_r:default_t 4096 2010-10-07 >> 09:36 .kbd >> -rw-------+ 1 root root root:object_r:default_t 43 2010-10-20 >> 16:23 .lesshst >> -rw-------+ 1 root root root:object_r:default_t 5520 2010-10-20 >> 16:02 .viminfo >> -rw-------+ 1 root root root:object_r:default_t 106 2010-10-20 >> 16:19 .Xauthority >> --- >> that's all right, isn't it? >> > > yeah the default_t is what I see over here as well..(just to make sure.. > youre not using sudo ssh name@xxxxxxxxxxx to do the sshd transaction, > just normally without root?) yes I'm just doing ssh mat@xxxxxxx or ssh root@xxxxxxx (both gets the same error..) > >> >> > > whats your home directory look like? for security reasons you dont need > to post all of it, just want to make sure the file contexts are correct > i.e. > I've noticed sometimes the file labels get labeled as > user:object_r:user_home_t:s0 > instead of > name:object_r:user_home_t:s0 > > the "user" part of the contexts under enforcement mode will show just > question marks and give no access to the file until you change "user" > to your login name (kind of a strange thing I've been noticing for one > reason or another.. probably because I never use genhomedircon or > something).. The home directory context of /root you see above. the one of mat_u looks like this: ls -alZ /home/mat/ total 7 drwxr-xr-x+ 2 mat_u root mat_u:object_r:user_home_dir_t 1024 2010-10-21 13:56 . drwxr-xr-x+ 5 root root system_u:object_r:home_root_t 1024 2010-10-19 16:06 .. -rw-------+ 1 mat_u users mat_u:object_r:user_home_t 220 2010-10-21 13:59 .bash_history -rw-------+ 1 mat_u users mat_u:object_r:xauth_home_t 0 2010-10-21 13:56 .Xauthority > > over here I have .ssh as name:object_r:ssh_home_t:s0 > and > ls -lZ /usr/sbin/sshd > system_u:object_r:sshd_exec_t:s0 > same thing here: ls -lZ /usr/sbin/sshd -rwxr-xr-x+ 1 root root system_u:object_r:sshd_exec_t 466560 2010-05-09 14:21 /usr/sbin/sshd > Justin P. Mattock > The problem of not being able to login must be in relation with permission denies while reading /etc/shadow type=AVC msg=audit(1287662213.439:407774): avc: denied { read } for pid=10211 comm="sshd" n ame="shadow" dev=dm-2 ino=48107 scontext=system_u:system_r:sshd_t tcontext=system_u:object_r:s hadow_t tclass=file type=AVC msg=audit(1287662236.391:407784): avc: denied { read } for pid=10214 comm="newrole " name="shadow" dev=dm-2 ino=48107 scontext=root:staff_r:newrole_t tcontext=system_u:object_r: shadow_t tclass=file neither sshd nor newrol are able to read /etc/shadow ls -alZ /etc/passwd -rw-r--r--+ 1 root root system_u:object_r:etc_t 1176 2010-10-19 16:45 /etc/passwd ls -alZ /usr/bin/passwd -rwsr-xr-x+ 1 root shadow system_u:object_r:passwd_exec_t 81856 2010-05-08 11:36 /usr/bin/passwd kind regards -- 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.
