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 o9KDk0TI003162 for ; Wed, 20 Oct 2010 09:46:00 -0400 Received: from mail-pw0-f53.google.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o9KDjwMU019680 for ; Wed, 20 Oct 2010 13:45:59 GMT Received: by pwj1 with SMTP id 1so722623pwj.12 for ; Wed, 20 Oct 2010 06:45:58 -0700 (PDT) Message-ID: <4CBEF2B4.3050408@gmail.com> Date: Wed, 20 Oct 2010 06:46:28 -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> In-Reply-To: <10617.193.5.216.100.1287564131.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/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.