-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/2010 04: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: >>>>>> > 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 >>>>>>> >>>>>>> >>>>>> >>>>>> 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. >> 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. >> >> 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. > 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? > 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? > Thanks a lot in advance >> 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. /root does not have labels on it. Probably genhomedircon was not run to setup labeling. In Fedora we label /root differently then refpolicy. The module_request could be caused by disabling ipv6? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky+4EgACgkQrlYvE4MpobPoxACfXKNE2iVcZHplWKs1u9JSHmKe xZcAn0rmA5Ns/zInQ0alHAxlfVT5p94I =xx/p -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
