>> On 28/09/10 16:10, imsand@xxxxxxxxx wrote: >>>> On 28/09/10 15:08, Daniel J Walsh wrote: >>>>>>>>>> What's wrong on my system? >>>>>>>>>> Why it's not possible to login even if selinux is in permissive >>>>>>>>>> mode? >>>>>>>>>> Any suggestions? >>>>>>>>> >>>>>>>>> I'd start by trying to figure out why sshd isn't running in >>>>>>>>> sshd_t >>>>>>>>> (it >>>>>>>>> seems to be running in sysadm_t). >>>>>>>>> >>>>>>>>> Paul. >>>>>>>>> >>>>>>>> >>>>>>>> Yes, sshd is running in sysadm_t: >>>>>>>> >>>>>>>> # ps axZ | grep sshd >>>>>>>> system_u:system_r:sysadm_t 3632 ? Ss 0:00 >>>>>>>> /usr/sbin/sshd >>>>>>>> -o PidFile=/var/run/sshd.init.pi >>>>>>>> >>>>>>>> # ls -Z /usr/sbin/sshd >>>>>>>> system_u:object_r:sshd_exec_t /usr/sbin/sshd >>>>>>>> >>>>>>>> Don't know why it's not sshd_t. I didn't modified something. It's >>>>>>>> a >>>>>>>> standard installation of sles11 with the default reference policy >>>>>>>> from >>>>>>>> tresys. >>>>>>>> >>>>>>>> Maybe this code snippet from policy/modules/services/ssh.te is >>>>>>>> responsible >>>>>>>> for that: >>>>>>>> ##<desc> >>>>>>>> ##<p> >>>>>>>> ## Allow ssh logins as sysadm_r:sysadm_t >>>>>>>> ##</p> >>>>>>>> ##</desc> >>>>>>>> gen_tunable(ssh_sysadm_login, true) >>>>>>>> >>>>>>>> Any ideas? >>>>>>> >>>>>>> Do you have boolean init_upstart set to on? if not try setting it >>>>>>> to >>>>>>> on. >>>>>>> I do not believe ssh_sysadm_login boolean works currently but i may >>>>>>> be >>>>>>> mistaken. >>>>>> >>>>>> Yeah, setting init_upstart to on did the trick! THANK A LOT! >>>>>> Do you know why this prevents the user from logging in through ssh >>>>>> even >>>>>> if >>>>>> selinux is set to permissive?? >>>>>> >>>>> Probably a bug in pam_selinux or sshd if it does not use pam_selinux. >>>>> Something is not respecting the permissive mode flag. Of course you >>>>> are >>>>> asking about sles on the Fedora mailing list.. :^) >>>> >>>> You'd see the same problem in Fedora if sshd wasn't running in sshd_t. >>>> The SSH server tries to compute the correct context for the session, >>>> fails, and bails out even in permissive mode. I saw this happen in the >>>> curl test suite, where we start an SSH server and try connecting to >>>> it. >>>> >>>> Paul. >>>> >>> After setting init_upstart = on sshd runs in sshd_t. >>> Do you know why? Can't sshd do a domain transition if init_upstart is >>> disabled? >> >> There's more on this here: >> >> https://bugzilla.novell.com/show_bug.cgi?id=582399 >> >> Paul. >> -- > Thank you for the link. I rename "/etc/initscript" like described it the > report. now, sshing is working in both cases (init_upstart = on | off). > Thats fine. > But the role transition still not work. > > > -- > selinux mailing list > selinux@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/selinux > I found out that the role transition works when the linux user name is equivalent to the SELinux name (both are mat_u). If so, the default user context after login via ssh is: "context=mat_u:staff_r:staff_t" And the explicit role transition to sysadm_r works as desired: "newrole -r sysadm_r" results in "context=mat_u:sysadm_r:sysadm_t". So far as I see, the user mapping seems to be correct: semanage login -l | grep mat Login Name SELinux User mat mat_u When I rename the Linux Login name back to mat, the role transition don't work anymore and the SELinux context switches back to "user_u:user_r:user_t" which is the default context if no correspond user is found by SELinux. Do I miss something? -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
