On 10/06/2010 12:29 AM, imsand at puzzle.ch wrote:
>> On 10/05/2010 11:43 PM, imsand at puzzle.ch wrote:
>>>> On 10/05/2010 06:38 AM, imsand at puzzle.ch wrote:
>>>>>> On 10/04/2010 11:30 PM, imsand at puzzle.ch wrote:
>>>>>>>> On 10/04/2010 01:03 AM, imsand at 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 at 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 at testsrv.example:~> newrole -r sysadm_r
>>>>>>>>> mat_u at 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 at 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 at 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 at 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 at 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?
>
>
>
looking at the above I don't see anything out of the in-ordinary..
except is, is if your initial role is staff_r going to sysadm_r will not
happen(not allowed to do that), if you start as sysadm_r then going to
staff_r, to sysadm_r is allow(but that(I don't think)doesn't explain the
wrong context that you keep getting.)
Opensuse I did run 11.2 there was issues here and there, but eventually
they were resolved. I do remember doing sshd while running that system,
and saw no issues i.e. changed sshd to have the logins at user_r for the
default contexts. lets add some cc's for this so you can get this
running properly(I only know so much about sshd)
Justin P. Mattock