From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o9LDYAX5020405 for ; Thu, 21 Oct 2010 09:34:10 -0400 Received: from mail-pv0-f181.google.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o9LDY7lH025494 for ; Thu, 21 Oct 2010 13:34:08 GMT Received: by pvg2 with SMTP id 2so1114086pvg.12 for ; Thu, 21 Oct 2010 06:34:04 -0700 (PDT) Message-ID: <4CC04146.4030904@gmail.com> Date: Thu, 21 Oct 2010 06:33:58 -0700 From: "Justin P. Mattock" MIME-Version: 1.0 To: imsand@puzzle.ch CC: Daniel J Walsh , Chad Sellers , selinux@tycho.nsa.gov Subject: Re: Context settings after ssh login References: <4CADF149.3040301@redhat.com> <4CAE025C.6010005@gmail.com> <44256.193.5.216.100.1287499358.squirrel@mail.puzzle.ch> <4CBDB14E.2030207@gmail.com> <12764.193.5.216.100.1287503226.squirrel@mail.puzzle.ch> <4CBDC997.6030800@gmail.com> <10617.193.5.216.100.1287564131.squirrel@mail.puzzle.ch> <4CBEF2B4.3050408@gmail.com> <35906.193.5.216.100.1287584724.squirrel@mail.puzzle.ch> <4CBF0235.2000802@gmail.com> <36626.193.5.216.100.1287662961.squirrel@mail.puzzle.ch> In-Reply-To: <36626.193.5.216.100.1287662961.squirrel@mail.puzzle.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On 10/21/2010 05:09 AM, imsand@puzzle.ch wrote: >> On 10/20/2010 07:25 AM, imsand@puzzle.ch wrote: >>>> On 10/20/2010 01:42 AM, imsand@puzzle.ch wrote: >>>>>> On 10/19/2010 08:47 AM, imsand@puzzle.ch wrote: >>>>>>>> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch" >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@puzzle.ch 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@testsrv.example:~> id >>>>>>>>>>>>>>>>>>>>> uid=6575(mat_u) gid=100(users) >>>>>>>>>>>>>>>>>>>>> groups=16(dialout),33(video),100(users) >>>>>>>>>>>>>>>>>>>>> context=mat_u:staff_r:staff_t >>>>>>>>>>>>>>>>>>>>> mat_u@testsrv.example:~> newrole -r sysadm_r >>>>>>>>>>>>>>>>>>>>> mat_u@testsrv.example:~> 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@testsrv.example:~> id >>>>>>>>>>>>>>>>>>>>> uid=6575(mat) gid=100(users) >>>>>>>>>>>>>>>>>>>>> groups=16(dialout),33(video),100(users) >>>>>>>>>>>>>>>>>>>>> context=user_u:user_r:user_t >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> mat_u@testsrv.example:~> 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@tycho.nsa.gov >>>>>>>>>>>>>>>>>>>>> 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@tycho.nsa.gov >>>>>>>>>>>>>>>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov >>>>>>>>>> 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@tycho.nsa.gov >>>> 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@x.x.x.x.x.x to do the sshd transaction, >> just normally without root?) > yes I'm just doing ssh mat@x.x.x.x or ssh root@x.x.x.x (both gets the same > error..) >> alright.. >>> >>> >> >> 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 just hit the annoying user_u here is what Im talking about: http://fpaste.org/fDUB/ (for security reason's I'll probably delete this system so it doesn't matter if the world See's the contents!!) >> 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 > > seem o.k. >> 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 > whats id -Z after you login? after you have defined all the rules have you done make enableaudit or semodule -DB to show the dontaudit rules? shadow avc's will appear but will never be allowed by the policy(same for root(sudo, su) at the moment). > kind regards > > 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.