> 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. > 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.
