error: ssh_selinux_getctxbyname: Failed to get default SELinux security context

imsand at puzzle.ch imsand at puzzle.ch
Thu Sep 30 11:37:46 UTC 2010


>> On 28/09/10 16:10, imsand at puzzle.ch 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 at lists.fedoraproject.org
> 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?




More information about the selinux mailing list