Context settings after ssh login

Context settings after ssh login

[imsand]

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@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@testsrv.example:~> newrole -r sysadm_r
mat_u@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@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@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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>  newrole -r sysadm_r
> mat_u@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@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@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@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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>  newrole -r sysadm_r
>> mat_u@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@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@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@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@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..



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>   newrole -r sysadm_r
>>> mat_u@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@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@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@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@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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>   newrole -r sysadm_r
>>>> mat_u@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@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@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@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@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?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>    newrole -r sysadm_r
>>>>> mat_u@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@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@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@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@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



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>    newrole -r sysadm_r
>>>>>> mat_u@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@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@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@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@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).


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>     newrole -r sysadm_r
>>>>>>> mat_u@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@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@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@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@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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>     newrole -r sysadm_r
>>>>>>>> mat_u@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@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@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@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@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?



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/06/2010 12:29 AM, imsand@puzzle.ch wrote:
>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>      newrole -r sysadm_r
>>>>>>>>> mat_u@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@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@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@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@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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] Context settings after ssh login

[Justin P. Mattock]

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

Re: Context settings after ssh login

[Chad Sellers]

On 10/6/10 3:29 AM, "imsand@puzzle.ch" <imsand@puzzle.ch> wrote:

>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>     newrole -r sysadm_r
>>>>>>>>> mat_u@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@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@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@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@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?
> 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/07/2010 10:40 AM, Chad Sellers wrote:
> On 10/6/10 3:29 AM, "imsand@puzzle.ch" <imsand@puzzle.ch> wrote:
> 
>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>     newrole -r sysadm_r
>>>>>>>>>> mat_u@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@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@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@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@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?
>>
> 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@tycho.nsa.gov 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-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

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@puzzle.ch"<imsand@puzzle.ch>  wrote:
>>
>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>      newrole -r sysadm_r
>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>
>> 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@tycho.nsa.gov 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

> 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@puzzle.ch"<imsand@puzzle.ch>  wrote:
>>>
>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>      newrole -r sysadm_r
>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>
>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
> 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.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>   wrote:
>>>>
>>>>          
>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>              
>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>                  
>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>                      
>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>       newrole -r sysadm_r
>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>
>>>>>            
>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>> 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



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>   wrote:
>>>>>
>>>>>
>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>>
>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>>
>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>       newrole -r sysadm_r
>>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>>
>>>>>>
>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>>> 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?




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/19/2010 08:47 AM, imsand@puzzle.ch wrote:
>> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>    wrote:
>>>>>>
>>>>>>
>>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>>>
>>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>>>
>>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>        newrole -r sysadm_r
>>>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>>>
>>>>>>>
>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>>>> 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--.)

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)

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

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

> On 10/19/2010 08:47 AM, imsand@puzzle.ch wrote:
>>> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>    wrote:
>>>>>>>
>>>>>>>
>>>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>>>>
>>>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>        newrole -r sysadm_r
>>>>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>>>>
>>>>>>>>
>>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>>>>> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/20/2010 04:42 AM, imsand@puzzle.ch wrote:
>> On 10/19/2010 08:47 AM, imsand@puzzle.ch wrote:
>>>> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>    wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>        newrole -r sysadm_r
>>>>>>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/20/2010 01:42 AM, imsand@puzzle.ch wrote:
>> On 10/19/2010 08:47 AM, imsand@puzzle.ch wrote:
>>>> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>     wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>
>>>>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>         newrole -r sysadm_r
>>>>>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>>>>>> 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.
>

cool... opensuse 11.2 was wrong(should be fixed now), causing SELinux to 
always look for targeted

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

the biggest issue is sles11.1 doesn't even use upstart.. this is caused by
/etc/initscript (just having that file present, causes things to go out 
of whack)

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

cool... you might need to make enableaudit or semodule -DB to show more 
avc's being denied

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

copy/pasting and using audit2allow -i file gets me nothing(format must 
be messd up or something), anyways dan is saying something about root in 
there name="root" so looking into what he had suggested is what probably 
needs to be done..
over here ls -lZ /root  shows
system_u:object_r:default_t:s0



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

thats a new one to me.. my guess is the file labels are wrong,
i.e. ubuntu had an issue a few yrs ago, to where /var/log/*
need to have restorecond -R /var done every-time at startup in order for 
the system to load into enforcement mode(with selinux-policy-default) 
but is fixed now.

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

> On 10/20/2010 01:42 AM, imsand@puzzle.ch wrote:
>>> On 10/19/2010 08:47 AM, imsand@puzzle.ch wrote:
>>>>> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>         newrole -r sysadm_r
>>>>>>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>>>>>>> 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.
>>
>
> cool... opensuse 11.2 was wrong(should be fixed now), causing SELinux to
> always look for targeted
>
>>> 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.
>>
>
> the biggest issue is sles11.1 doesn't even use upstart.. this is caused by
> /etc/initscript (just having that file present, causes things to go out
> of whack)
>
>>>
>>> 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.
>>
>
> cool... you might need to make enableaudit or semodule -DB to show more
> avc's being denied
>
>> 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?
>>
>
> copy/pasting and using audit2allow -i file gets me nothing(format must
> be messd up or something), anyways dan is saying something about root in
> there name="root" so looking into what he had suggested is what probably
> needs to be done..
> over here ls -lZ /root  shows
> system_u:object_r:default_t:s0
>
>
>
>>
>> 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?
>>
>
> thats a new one to me.. my guess is the file labels are wrong,
> i.e. ubuntu had an issue a few yrs ago, to where /var/log/*
> need to have restorecond -R /var done every-time at startup in order for
> the system to load into enforcement mode(with selinux-policy-default)
> but is fixed now.
>
> 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@tycho.nsa.gov
> with
> the words "unsubscribe selinux" without quotes as the message.
>


okey, here are some more infos regarding the login process:
----
type=AVC msg=audit(1287584199.835:407448): avc:  denied  { read } for 
pid=3850 comm="sshd" name="shadow" dev=dm-2
ino=48107 scontext=system_u:system_r:sshd_t
tcontext=system_u:object_r:shadow_t tclass=file
type=AVC msg=audit(1287584199.835:407449): avc:  denied  { open } for 
pid=3850 comm="sshd" name="shadow" dev=dm-2
ino=48107 scontext=system_u:system_r:sshd_t
tcontext=system_u:object_r:shadow_t tclass=file
type=AVC msg=audit(1287584199.835:407450): avc:  denied  { getattr } for 
pid=3850 comm="sshd" path="/etc/shadow" d
ev=dm-2 ino=48107 scontext=system_u:system_r:sshd_t
tcontext=system_u:object_r:shadow_t tclass=file
----
seems that sshd isn't able to access /etc/shadow. shouldn't that be
allowed by default??
The /root context looks like this:
---
drwx------+   6 root root system_u:object_r:default_t     4096 2010-10-20
16:23 root
---
---
drwx------+  6 root root system_u:object_r:default_t  4096 2010-10-20 16:23 .
drwxr-xr-x+ 24 root root system_u:object_r:root_t     4096 2010-10-20
16:14 ..
-rw-------+  1 root root system_u:object_r:default_t  7133 2010-10-20
16:13 .bash_history
drwxr-xr-x+  2 root root system_u:object_r:default_t  4096 2010-05-05
16:04 bin
-rw-r--r--+  1 root root system_u:object_r:default_t 40014 2010-10-07
09:38 cobbler_autoyast.xml
-rw-r--r--+  1 root root system_u:object_r:default_t  1332 2005-11-23
17:06 .exrc
-rw-r-----+  1 root root system_u:object_r:default_t     4 2010-10-07
10:15 .forward
drwx------+  2 root root system_u:object_r:default_t  4096 2010-10-07
10:44 .gnupg
drwxr-xr-x+  5 root root system_u:object_r:default_t  4096 2010-10-07
09:20 inst-sys
drwxr-xr-x+  2 root root system_u:object_r:default_t  4096 2010-10-07
09:36 .kbd
-rw-------+  1 root root root:object_r:default_t        43 2010-10-20
16:23 .lesshst
-rw-------+  1 root root root:object_r:default_t      5520 2010-10-20
16:02 .viminfo
-rw-------+  1 root root root:object_r:default_t       106 2010-10-20
16:19 .Xauthority
---
that's all right, isn't it?



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/20/2010 07:25 AM, imsand@puzzle.ch wrote:
>> On 10/20/2010 01:42 AM, imsand@puzzle.ch wrote:
>>>> On 10/19/2010 08:47 AM, imsand@puzzle.ch wrote:
>>>>>> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>          newrole -r sysadm_r
>>>>>>>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>>>>>>>> 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.
>>>
>>
>> cool... opensuse 11.2 was wrong(should be fixed now), causing SELinux to
>> always look for targeted
>>
>>>> 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.
>>>
>>
>> the biggest issue is sles11.1 doesn't even use upstart.. this is caused by
>> /etc/initscript (just having that file present, causes things to go out
>> of whack)
>>
>>>>
>>>> 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.
>>>
>>
>> cool... you might need to make enableaudit or semodule -DB to show more
>> avc's being denied
>>
>>> 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?
>>>
>>
>> copy/pasting and using audit2allow -i file gets me nothing(format must
>> be messd up or something), anyways dan is saying something about root in
>> there name="root" so looking into what he had suggested is what probably
>> needs to be done..
>> over here ls -lZ /root  shows
>> system_u:object_r:default_t:s0
>>
>>
>>
>>>
>>> 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?
>>>
>>
>> thats a new one to me.. my guess is the file labels are wrong,
>> i.e. ubuntu had an issue a few yrs ago, to where /var/log/*
>> need to have restorecond -R /var done every-time at startup in order for
>> the system to load into enforcement mode(with selinux-policy-default)
>> but is fixed now.
>>
>> 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@tycho.nsa.gov
>> with
>> the words "unsubscribe selinux" without quotes as the message.
>>
>
>
> okey, here are some more infos regarding the login process:
> ----
> type=AVC msg=audit(1287584199.835:407448): avc:  denied  { read } for
> pid=3850 comm="sshd" name="shadow" dev=dm-2
> ino=48107 scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:shadow_t tclass=file
> type=AVC msg=audit(1287584199.835:407449): avc:  denied  { open } for
> pid=3850 comm="sshd" name="shadow" dev=dm-2
> ino=48107 scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:shadow_t tclass=file
> type=AVC msg=audit(1287584199.835:407450): avc:  denied  { getattr } for
> pid=3850 comm="sshd" path="/etc/shadow" d
> ev=dm-2 ino=48107 scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:shadow_t tclass=file
> ----
> seems that sshd isn't able to access /etc/shadow. shouldn't that be
> allowed by default??
> The /root context looks like this:

I think I misunderstood what dan was talking about by posting the 
context of /root (but could be wrong).. I think whats wrong here is
/etc/shadow you should be seeing avc's with chkpwd_exec_t which
pam_selinux.so is responsible for doing

when you login(after xdm/gdm) whats id -Z look like?
over here I have name:staff_r:staff_t:s0

> ---
> drwx------+   6 root root system_u:object_r:default_t     4096 2010-10-20
> 16:23 root
> ---
> ---
> drwx------+  6 root root system_u:object_r:default_t  4096 2010-10-20 16:23 .
> drwxr-xr-x+ 24 root root system_u:object_r:root_t     4096 2010-10-20
> 16:14 ..
> -rw-------+  1 root root system_u:object_r:default_t  7133 2010-10-20
> 16:13 .bash_history
> drwxr-xr-x+  2 root root system_u:object_r:default_t  4096 2010-05-05
> 16:04 bin
> -rw-r--r--+  1 root root system_u:object_r:default_t 40014 2010-10-07
> 09:38 cobbler_autoyast.xml
> -rw-r--r--+  1 root root system_u:object_r:default_t  1332 2005-11-23
> 17:06 .exrc
> -rw-r-----+  1 root root system_u:object_r:default_t     4 2010-10-07
> 10:15 .forward
> drwx------+  2 root root system_u:object_r:default_t  4096 2010-10-07
> 10:44 .gnupg
> drwxr-xr-x+  5 root root system_u:object_r:default_t  4096 2010-10-07
> 09:20 inst-sys
> drwxr-xr-x+  2 root root system_u:object_r:default_t  4096 2010-10-07
> 09:36 .kbd
> -rw-------+  1 root root root:object_r:default_t        43 2010-10-20
> 16:23 .lesshst
> -rw-------+  1 root root root:object_r:default_t      5520 2010-10-20
> 16:02 .viminfo
> -rw-------+  1 root root root:object_r:default_t       106 2010-10-20
> 16:19 .Xauthority
> ---
> that's all right, isn't it?
>

yeah the default_t is what I see over here as well..(just to make sure.. 
youre not using sudo ssh name@x.x.x.x.x.x to do the sshd transaction, 
just normally without root?)

>
>

whats your home directory look like? for security reasons you dont need 
to post all of it, just want to make sure the file contexts are correct i.e.
I've noticed sometimes the file labels get labeled as
user:object_r:user_home_t:s0
instead of
name:object_r:user_home_t:s0

the "user" part of the contexts under enforcement mode will show just 
question marks and give no access to the file until you change "user"
to your login name (kind of a strange thing I've been noticing for one 
reason or another.. probably because I never use genhomedircon or 
something)..

over here I have .ssh as name:object_r:ssh_home_t:s0
and
ls -lZ /usr/sbin/sshd
system_u:object_r:sshd_exec_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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

> On 10/20/2010 07:25 AM, imsand@puzzle.ch wrote:
>>> On 10/20/2010 01:42 AM, imsand@puzzle.ch wrote:
>>>>> On 10/19/2010 08:47 AM, imsand@puzzle.ch wrote:
>>>>>>> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>          newrole -r sysadm_r
>>>>>>>>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>>>>>>>>> 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.
>>>>
>>>
>>> cool... opensuse 11.2 was wrong(should be fixed now), causing SELinux
>>> to
>>> always look for targeted
>>>
>>>>> 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.
>>>>
>>>
>>> the biggest issue is sles11.1 doesn't even use upstart.. this is caused
>>> by
>>> /etc/initscript (just having that file present, causes things to go out
>>> of whack)
>>>
>>>>>
>>>>> 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.
>>>>
>>>
>>> cool... you might need to make enableaudit or semodule -DB to show more
>>> avc's being denied
>>>
>>>> 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?
>>>>
>>>
>>> copy/pasting and using audit2allow -i file gets me nothing(format must
>>> be messd up or something), anyways dan is saying something about root
>>> in
>>> there name="root" so looking into what he had suggested is what
>>> probably
>>> needs to be done..
>>> over here ls -lZ /root  shows
>>> system_u:object_r:default_t:s0
>>>
>>>
>>>
>>>>
>>>> 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?
>>>>
>>>
>>> thats a new one to me.. my guess is the file labels are wrong,
>>> i.e. ubuntu had an issue a few yrs ago, to where /var/log/*
>>> need to have restorecond -R /var done every-time at startup in order
>>> for
>>> the system to load into enforcement mode(with selinux-policy-default)
>>> but is fixed now.
>>>
>>> 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@tycho.nsa.gov
>>> with
>>> the words "unsubscribe selinux" without quotes as the message.
>>>
>>
>>
>> okey, here are some more infos regarding the login process:
>> ----
>> type=AVC msg=audit(1287584199.835:407448): avc:  denied  { read } for
>> pid=3850 comm="sshd" name="shadow" dev=dm-2
>> ino=48107 scontext=system_u:system_r:sshd_t
>> tcontext=system_u:object_r:shadow_t tclass=file
>> type=AVC msg=audit(1287584199.835:407449): avc:  denied  { open } for
>> pid=3850 comm="sshd" name="shadow" dev=dm-2
>> ino=48107 scontext=system_u:system_r:sshd_t
>> tcontext=system_u:object_r:shadow_t tclass=file
>> type=AVC msg=audit(1287584199.835:407450): avc:  denied  { getattr } for
>> pid=3850 comm="sshd" path="/etc/shadow" d
>> ev=dm-2 ino=48107 scontext=system_u:system_r:sshd_t
>> tcontext=system_u:object_r:shadow_t tclass=file
>> ----
>> seems that sshd isn't able to access /etc/shadow. shouldn't that be
>> allowed by default??
>> The /root context looks like this:
>
> I think I misunderstood what dan was talking about by posting the
> context of /root (but could be wrong).. I think whats wrong here is
> /etc/shadow you should be seeing avc's with chkpwd_exec_t which
> pam_selinux.so is responsible for doing
>
> when you login(after xdm/gdm) whats id -Z look like?
> over here I have name:staff_r:staff_t:s0
>
>> ---
>> drwx------+   6 root root system_u:object_r:default_t     4096
>> 2010-10-20
>> 16:23 root
>> ---
>> ---
>> drwx------+  6 root root system_u:object_r:default_t  4096 2010-10-20
>> 16:23 .
>> drwxr-xr-x+ 24 root root system_u:object_r:root_t     4096 2010-10-20
>> 16:14 ..
>> -rw-------+  1 root root system_u:object_r:default_t  7133 2010-10-20
>> 16:13 .bash_history
>> drwxr-xr-x+  2 root root system_u:object_r:default_t  4096 2010-05-05
>> 16:04 bin
>> -rw-r--r--+  1 root root system_u:object_r:default_t 40014 2010-10-07
>> 09:38 cobbler_autoyast.xml
>> -rw-r--r--+  1 root root system_u:object_r:default_t  1332 2005-11-23
>> 17:06 .exrc
>> -rw-r-----+  1 root root system_u:object_r:default_t     4 2010-10-07
>> 10:15 .forward
>> drwx------+  2 root root system_u:object_r:default_t  4096 2010-10-07
>> 10:44 .gnupg
>> drwxr-xr-x+  5 root root system_u:object_r:default_t  4096 2010-10-07
>> 09:20 inst-sys
>> drwxr-xr-x+  2 root root system_u:object_r:default_t  4096 2010-10-07
>> 09:36 .kbd
>> -rw-------+  1 root root root:object_r:default_t        43 2010-10-20
>> 16:23 .lesshst
>> -rw-------+  1 root root root:object_r:default_t      5520 2010-10-20
>> 16:02 .viminfo
>> -rw-------+  1 root root root:object_r:default_t       106 2010-10-20
>> 16:19 .Xauthority
>> ---
>> that's all right, isn't it?
>>
>
> yeah the default_t is what I see over here as well..(just to make sure..
> youre not using sudo ssh name@x.x.x.x.x.x to do the sshd transaction,
> just normally without root?)
yes I'm just doing ssh mat@x.x.x.x or ssh root@x.x.x.x (both gets the same
error..)
>
>>
>>
>
> whats your home directory look like? for security reasons you dont need
> to post all of it, just want to make sure the file contexts are correct
> i.e.
> I've noticed sometimes the file labels get labeled as
> user:object_r:user_home_t:s0
> instead of
> name:object_r:user_home_t:s0
>
> the "user" part of the contexts under enforcement mode will show just
> question marks and give no access to the file until you change "user"
> to your login name (kind of a strange thing I've been noticing for one
> reason or another.. probably because I never use genhomedircon or
> something)..
The home directory context of /root you see above. the one of mat_u looks
like this:
ls -alZ /home/mat/
total 7
drwxr-xr-x+ 2 mat_u root  mat_u:object_r:user_home_dir_t 1024 2010-10-21
13:56 .
drwxr-xr-x+ 5 root  root  system_u:object_r:home_root_t  1024 2010-10-19
16:06 ..
-rw-------+ 1 mat_u users mat_u:object_r:user_home_t      220 2010-10-21
13:59 .bash_history
-rw-------+ 1 mat_u users mat_u:object_r:xauth_home_t       0 2010-10-21
13:56 .Xauthority

>
> over here I have .ssh as name:object_r:ssh_home_t:s0
> and
> ls -lZ /usr/sbin/sshd
> system_u:object_r:sshd_exec_t:s0
>
same thing here:

ls -lZ /usr/sbin/sshd
-rwxr-xr-x+ 1 root root system_u:object_r:sshd_exec_t 466560 2010-05-09
14:21 /usr/sbin/sshd


> Justin P. Mattock
>
The problem of not being able to login must be in relation with permission
denies while reading /etc/shadow
type=AVC msg=audit(1287662213.439:407774): avc:  denied  { read } for 
pid=10211 comm="sshd" n
ame="shadow" dev=dm-2 ino=48107 scontext=system_u:system_r:sshd_t
tcontext=system_u:object_r:s
hadow_t tclass=file

type=AVC msg=audit(1287662236.391:407784): avc:  denied  { read } for 
pid=10214 comm="newrole
" name="shadow" dev=dm-2 ino=48107 scontext=root:staff_r:newrole_t
tcontext=system_u:object_r:
shadow_t tclass=file

neither sshd nor newrol are able to read /etc/shadow
ls -alZ /etc/passwd
-rw-r--r--+ 1 root root system_u:object_r:etc_t 1176 2010-10-19 16:45
/etc/passwd

ls -alZ /usr/bin/passwd
-rwsr-xr-x+ 1 root shadow system_u:object_r:passwd_exec_t 81856 2010-05-08
11:36 /usr/bin/passwd

kind regards


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

On 10/21/2010 05:09 AM, imsand@puzzle.ch wrote:
>> On 10/20/2010 07:25 AM, imsand@puzzle.ch wrote:
>>>> On 10/20/2010 01:42 AM, imsand@puzzle.ch wrote:
>>>>>> On 10/19/2010 08:47 AM, imsand@puzzle.ch wrote:
>>>>>>>> On 10/19/2010 07:42 AM, imsand@puzzle.ch 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@puzzle.ch"<imsand@puzzle.ch>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 10/04/2010 01:03 AM, imsand@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@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@testsrv.example:~>           newrole -r sysadm_r
>>>>>>>>>>>>>>>>>>>>> mat_u@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@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@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@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@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?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> 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@tycho.nsa.gov 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@tycho.nsa.gov
>>>>>>>>>> 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.
>>>>>
>>>>
>>>> cool... opensuse 11.2 was wrong(should be fixed now), causing SELinux
>>>> to
>>>> always look for targeted
>>>>
>>>>>> 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.
>>>>>
>>>>
>>>> the biggest issue is sles11.1 doesn't even use upstart.. this is caused
>>>> by
>>>> /etc/initscript (just having that file present, causes things to go out
>>>> of whack)
>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>
>>>> cool... you might need to make enableaudit or semodule -DB to show more
>>>> avc's being denied
>>>>
>>>>> 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?
>>>>>
>>>>
>>>> copy/pasting and using audit2allow -i file gets me nothing(format must
>>>> be messd up or something), anyways dan is saying something about root
>>>> in
>>>> there name="root" so looking into what he had suggested is what
>>>> probably
>>>> needs to be done..
>>>> over here ls -lZ /root  shows
>>>> system_u:object_r:default_t:s0
>>>>
>>>>
>>>>
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>> thats a new one to me.. my guess is the file labels are wrong,
>>>> i.e. ubuntu had an issue a few yrs ago, to where /var/log/*
>>>> need to have restorecond -R /var done every-time at startup in order
>>>> for
>>>> the system to load into enforcement mode(with selinux-policy-default)
>>>> but is fixed now.
>>>>
>>>> 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@tycho.nsa.gov
>>>> with
>>>> the words "unsubscribe selinux" without quotes as the message.
>>>>
>>>
>>>
>>> okey, here are some more infos regarding the login process:
>>> ----
>>> type=AVC msg=audit(1287584199.835:407448): avc:  denied  { read } for
>>> pid=3850 comm="sshd" name="shadow" dev=dm-2
>>> ino=48107 scontext=system_u:system_r:sshd_t
>>> tcontext=system_u:object_r:shadow_t tclass=file
>>> type=AVC msg=audit(1287584199.835:407449): avc:  denied  { open } for
>>> pid=3850 comm="sshd" name="shadow" dev=dm-2
>>> ino=48107 scontext=system_u:system_r:sshd_t
>>> tcontext=system_u:object_r:shadow_t tclass=file
>>> type=AVC msg=audit(1287584199.835:407450): avc:  denied  { getattr } for
>>> pid=3850 comm="sshd" path="/etc/shadow" d
>>> ev=dm-2 ino=48107 scontext=system_u:system_r:sshd_t
>>> tcontext=system_u:object_r:shadow_t tclass=file
>>> ----
>>> seems that sshd isn't able to access /etc/shadow. shouldn't that be
>>> allowed by default??
>>> The /root context looks like this:
>>
>> I think I misunderstood what dan was talking about by posting the
>> context of /root (but could be wrong).. I think whats wrong here is
>> /etc/shadow you should be seeing avc's with chkpwd_exec_t which
>> pam_selinux.so is responsible for doing
>>
>> when you login(after xdm/gdm) whats id -Z look like?
>> over here I have name:staff_r:staff_t:s0
>>
>>> ---
>>> drwx------+   6 root root system_u:object_r:default_t     4096
>>> 2010-10-20
>>> 16:23 root
>>> ---
>>> ---
>>> drwx------+  6 root root system_u:object_r:default_t  4096 2010-10-20
>>> 16:23 .
>>> drwxr-xr-x+ 24 root root system_u:object_r:root_t     4096 2010-10-20
>>> 16:14 ..
>>> -rw-------+  1 root root system_u:object_r:default_t  7133 2010-10-20
>>> 16:13 .bash_history
>>> drwxr-xr-x+  2 root root system_u:object_r:default_t  4096 2010-05-05
>>> 16:04 bin
>>> -rw-r--r--+  1 root root system_u:object_r:default_t 40014 2010-10-07
>>> 09:38 cobbler_autoyast.xml
>>> -rw-r--r--+  1 root root system_u:object_r:default_t  1332 2005-11-23
>>> 17:06 .exrc
>>> -rw-r-----+  1 root root system_u:object_r:default_t     4 2010-10-07
>>> 10:15 .forward
>>> drwx------+  2 root root system_u:object_r:default_t  4096 2010-10-07
>>> 10:44 .gnupg
>>> drwxr-xr-x+  5 root root system_u:object_r:default_t  4096 2010-10-07
>>> 09:20 inst-sys
>>> drwxr-xr-x+  2 root root system_u:object_r:default_t  4096 2010-10-07
>>> 09:36 .kbd
>>> -rw-------+  1 root root root:object_r:default_t        43 2010-10-20
>>> 16:23 .lesshst
>>> -rw-------+  1 root root root:object_r:default_t      5520 2010-10-20
>>> 16:02 .viminfo
>>> -rw-------+  1 root root root:object_r:default_t       106 2010-10-20
>>> 16:19 .Xauthority
>>> ---
>>> that's all right, isn't it?
>>>
>>
>> yeah the default_t is what I see over here as well..(just to make sure..
>> youre not using sudo ssh name@x.x.x.x.x.x to do the sshd transaction,
>> just normally without root?)
> yes I'm just doing ssh mat@x.x.x.x or ssh root@x.x.x.x (both gets the same
> error..)
>>

alright..

>>>
>>>
>>
>> whats your home directory look like? for security reasons you dont need
>> to post all of it, just want to make sure the file contexts are correct
>> i.e.
>> I've noticed sometimes the file labels get labeled as
>> user:object_r:user_home_t:s0
>> instead of
>> name:object_r:user_home_t:s0
>>
>> the "user" part of the contexts under enforcement mode will show just
>> question marks and give no access to the file until you change "user"
>> to your login name (kind of a strange thing I've been noticing for one
>> reason or another.. probably because I never use genhomedircon or
>> something)..
> The home directory context of /root you see above. the one of mat_u looks
> like this:
> ls -alZ /home/mat/
> total 7
> drwxr-xr-x+ 2 mat_u root  mat_u:object_r:user_home_dir_t 1024 2010-10-21
> 13:56 .
> drwxr-xr-x+ 5 root  root  system_u:object_r:home_root_t  1024 2010-10-19
> 16:06 ..
> -rw-------+ 1 mat_u users mat_u:object_r:user_home_t      220 2010-10-21
> 13:59 .bash_history
> -rw-------+ 1 mat_u users mat_u:object_r:xauth_home_t       0 2010-10-21
> 13:56 .Xauthority
>
>>

over here just hit the annoying user_u here is what Im talking about:
http://fpaste.org/fDUB/
(for security reason's I'll probably delete this system so it doesn't 
matter if the world See's the contents!!)

>> over here I have .ssh as name:object_r:ssh_home_t:s0
>> and
>> ls -lZ /usr/sbin/sshd
>> system_u:object_r:sshd_exec_t:s0
>>
> same thing here:
>
> ls -lZ /usr/sbin/sshd
> -rwxr-xr-x+ 1 root root system_u:object_r:sshd_exec_t 466560 2010-05-09
> 14:21 /usr/sbin/sshd
>
>

seem o.k.

>> Justin P. Mattock
>>
> The problem of not being able to login must be in relation with permission
> denies while reading /etc/shadow
> type=AVC msg=audit(1287662213.439:407774): avc:  denied  { read } for
> pid=10211 comm="sshd" n
> ame="shadow" dev=dm-2 ino=48107 scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:s
> hadow_t tclass=file
>
> type=AVC msg=audit(1287662236.391:407784): avc:  denied  { read } for
> pid=10214 comm="newrole
> " name="shadow" dev=dm-2 ino=48107 scontext=root:staff_r:newrole_t
> tcontext=system_u:object_r:
> shadow_t tclass=file
>
> neither sshd nor newrol are able to read /etc/shadow
> ls -alZ /etc/passwd
> -rw-r--r--+ 1 root root system_u:object_r:etc_t 1176 2010-10-19 16:45
> /etc/passwd
>
> ls -alZ /usr/bin/passwd
> -rwsr-xr-x+ 1 root shadow system_u:object_r:passwd_exec_t 81856 2010-05-08
> 11:36 /usr/bin/passwd
>

whats id -Z after you login?

after you have defined all the rules have you done make enableaudit or 
semodule -DB to show the dontaudit rules?
shadow avc's will appear but will never be allowed by the policy(same 
for root(sudo, su) at the moment).

> kind regards
>
>

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

o.k. cleaned up this thread due to it becoming cluttered..

Right now I went and installed sles11.1 unto my machine, and got the 
policy up and running.(just have not defined any allow rules yet).

when using my iphone to sshd into the sles11.1 system Im going into the 
proper context that it should, as well as using another machine with 
SELinux on it.
If I sshd with sles11.1 into the other machine with SELinux I have the 
wrong login context, as well as using the iphone..
both give this:
iphone/sles11.1 sshd too------>other machine with SELinux gives:
id -Z
system_u:system_r:unconfined_t:s0-s0:c0.c1023

from what I remember I was doing vnc/sshd a few months ago with ipsec, 
and this was working..

abit late over here now, but what I can do is reload the system that I 
compressed and know works, to see if things are running properly, then 
see if I can narrow this down to a bisect or something.

as for sles11.1 itself the only real packages I needed to grab from the 
opensuse repos was git for the kernel, the rest is on the dvd..
(mixing sles11.1 and opensuse 11.1 breaks lots of things...)

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

hmm... seem to be receiving this
     **********************************************
     **      THIS IS A WARNING MESSAGE ONLY      **
     **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
     **********************************************

The original message was received at Sat, 23 Oct 2010 06:27:55 GMT
from localhost [127.0.0.1]

when sending to selinux...(I have no idea what this is..)

Anyways I fixed(hopefully) the context issue over here(hopefully your 
experiencing something similar)

long story short when I built this package I had left out the
--with-selinux and the --with-pam switches(must have been too tired or 
something)
Anyways now Im able to login and have the correct context with both 
machines(sles11.1, and standard SELinux system)

Im wondering if they might have done the same for you?
(for pam you can change sshd to go to pam by modifying /etc/ssh/sshd_config)

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Russell Coker]

On Thu, 21 Oct 2010, imsand@puzzle.ch wrote:
> The problem of not being able to login must be in relation with permission
> denies while reading /etc/shadow
> type=AVC msg=audit(1287662213.439:407774): avc:  denied  { read } for 
> pid=10211 comm="sshd" n
> ame="shadow" dev=dm-2 ino=48107 scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:s
> hadow_t tclass=file

The way it's supposed to work is that unix_chkpwd will read /etc/shadow and 
tell the caller (sshd or whatever) whether the password matched.  That means 
that sshd doesn't get read access to /etc/shadow and if it's compromised it 
can't give such data away to random attackers.

Using a compromised sshd to read /etc/shadow isn't one of the more likely 
attacks (the existence of such an exploit would rely on there being a sshd 
bug, and it being impossible to launch a shell with said bug).  But it's an 
easy one to protect against.

If you have a non-PAM system then you need to allow such access though.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[imsand]

Hi Justin.

First of all, thanks a lot for your efforts.

Unfortunately I'm a little bit confused about what you've done exactly to
make it run.
Can you please summarize it and make a little step by step guide for me?

Did selinux worked out of the box (on sles11.1)? Didn't had you have to
fix the bug in /lib/mkinitrd/scripts/boot-boot.sh and rebuild initrd?

which package have you build with --with-selinux and the --with-pam?

which policy did you used? http://oss.tresys.com/git/refpolicy.git?

kind regards
Matthias

> hmm... seem to be receiving this
>      **********************************************
>      **      THIS IS A WARNING MESSAGE ONLY      **
>      **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
>      **********************************************
>
> The original message was received at Sat, 23 Oct 2010 06:27:55 GMT
> from localhost [127.0.0.1]
>
> when sending to selinux...(I have no idea what this is..)
>
> Anyways I fixed(hopefully) the context issue over here(hopefully your
> experiencing something similar)
>
> long story short when I built this package I had left out the
> --with-selinux and the --with-pam switches(must have been too tired or
> something)
> Anyways now Im able to login and have the correct context with both
> machines(sles11.1, and standard SELinux system)
>
> Im wondering if they might have done the same for you?
> (for pam you can change sshd to go to pam by modifying
> /etc/ssh/sshd_config)
>
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

[-- Attachment #1: Type: text/plain, Size: 1961 bytes --]

  On 10/25/2010 12:09 AM, imsand@puzzle.ch wrote:
> Hi Justin.
>
> First of all, thanks a lot for your efforts.

youre welcome!!
> Unfortunately I'm a little bit confused about what you've done exactly to
> make it run.
> Can you please summarize it and make a little step by step guide for me?

I can try, but maybe later on another post(a bit late over here.)
> Did selinux worked out of the box (on sles11.1)? Didn't had you have to
> fix the bug in /lib/mkinitrd/scripts/boot-boot.sh and rebuild initrd?

long story short, installed sles11.1, changed the repos to download git-core
then changed repos to download the rest of the packages to build the 
latest Mainline kernel
(make, make modules_install)
then after that, installed all the SELinux packages, rebooted realized 
even though this system is
using sysvinit the policy still wont load without an initrd(must be 
because my other systems have
_nothing_ of the sort with initrd in them(*.h)or something, so ended up 
using mkinitrd_setup to make the image
so the policy can load..

Then once loaded made sure the home directory was labelled correctly, as 
well as other
areas that I've seen issues with, then just started the sshd..with the 
other machine with SELinux,
and the iphone(touchterm ssh(free))..

> which package have you build with --with-selinux and the --with-pam?
this was on my cblfs system.. I just built this(all gnome etc..)and 
didnt realize that I had
built this wrong until I looked at config.log of the package and noticed 
I messd up..

after that things went good..(from over here sles11.1 sshd looks built 
fine, maybe this is config issues..,
only issue I noticed is getsebool/setsebool are missing, so just do: mv 
/etc/initscript{,-old}
to avoid problems during boot, or define the init_upstart boolean in 
boolean.conf.)

> which policy did you used? http://oss.tresys.com/git/refpolicy.git?
>

yep... I follow track

> kind regards
> Matthias
>
>

Justin P. Mattock


[-- Attachment #2: Type: text/html, Size: 3600 bytes --]

Re: Context settings after ssh login

[Justin P. Mattock]

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]

  On 10/25/2010 12:57 AM, Justin P. Mattock wrote:
> On 10/25/2010 12:09 AM, imsand@puzzle.ch wrote:
>> Hi Justin.
>>
>> First of all, thanks a lot for your efforts.
>
> youre welcome!!
>> Unfortunately I'm a little bit confused about what you've done exactly to
>> make it run.
>> Can you please summarize it and make a little step by step guide for me?
>
> I can try, but maybe later on another post(a bit late over here.)
>> Did selinux worked out of the box (on sles11.1)? Didn't had you have to
>> fix the bug in /lib/mkinitrd/scripts/boot-boot.sh and rebuild initrd?
>
> long story short, installed sles11.1, changed the repos to download 
> git-core
> then changed repos to download the rest of the packages to build the 
> latest Mainline kernel
> (make, make modules_install)
> then after that, installed all the SELinux packages, rebooted realized 
> even though this system is
> using sysvinit the policy still wont load without an initrd(must be 
> because my other systems have
> _nothing_ of the sort with initrd in them(*.h)or something, so ended 
> up using mkinitrd_setup to make the image
> so the policy can load..
>
> Then once loaded made sure the home directory was labelled correctly, 
> as well as other
> areas that I've seen issues with, then just started the sshd..with the 
> other machine with SELinux,
> and the iphone(touchterm ssh(free))..
>
>> which package have you build with --with-selinux and the --with-pam?
> this was on my cblfs system.. I just built this(all gnome etc..)and 
> didnt realize that I had
> built this wrong until I looked at config.log of the package and 
> noticed I messd up..
>
> after that things went good..(from over here sles11.1 sshd looks built 
> fine, maybe this is config issues..,
> only issue I noticed is getsebool/setsebool are missing, so just do: 
> mv /etc/initscript{,-old}
> to avoid problems during boot, or define the init_upstart boolean in 
> boolean.conf.)
>
>> which policy did you used?http://oss.tresys.com/git/refpolicy.git?
>>
>
> yep... I follow track
>
>> kind regards
>> Matthias
>>
>>
>
> Justin P. Mattock
>

FWIW heres the system info with SELinux and sles11.1:
http://fpaste.org/hdTI/

Justin P. Mattock

[-- Attachment #2: Type: text/html, Size: 4231 bytes --]

Re: Context settings after ssh login

[imsand]

>   On 10/25/2010 12:57 AM, Justin P. Mattock wrote:
>> On 10/25/2010 12:09 AM, imsand@puzzle.ch wrote:
>>> Hi Justin.
>>>
>>> First of all, thanks a lot for your efforts.
>>
>> youre welcome!!
>>> Unfortunately I'm a little bit confused about what you've done exactly
>>> to
>>> make it run.
>>> Can you please summarize it and make a little step by step guide for
>>> me?
>>
>> I can try, but maybe later on another post(a bit late over here.)
>>> Did selinux worked out of the box (on sles11.1)? Didn't had you have to
>>> fix the bug in /lib/mkinitrd/scripts/boot-boot.sh and rebuild initrd?
>>
>> long story short, installed sles11.1, changed the repos to download
>> git-core
>> then changed repos to download the rest of the packages to build the
>> latest Mainline kernel
>> (make, make modules_install)
On my installation I took the original kernel, shipped with sles11.1. I
don't want to compile a new one unless it's strongly recommended. Why
don't you use the original kernel and packages of sles11.1?
>> then after that, installed all the SELinux packages, rebooted realized
>> even though this system is
>> using sysvinit the policy still wont load without an initrd(must be
>> because my other systems have
>> _nothing_ of the sort with initrd in them(*.h)or something, so ended
>> up using mkinitrd_setup to make the image
>> so the policy can load..
>>
Okey. I also had to rebuild initrd with the adjustments I already described.
>> Then once loaded made sure the home directory was labelled correctly,
>> as well as other
>> areas that I've seen issues with, then just started the sshd..with the
>> other machine with SELinux,
>> and the iphone(touchterm ssh(free))..
>>
>>> which package have you build with --with-selinux and the --with-pam?
I did't rebuild any packages. Do I have to recomple some packages with
these options? I just took the original versions, shipped with sles 11.1.
>> this was on my cblfs system.. I just built this(all gnome etc..)and
>> didnt realize that I had
>> built this wrong until I looked at config.log of the package and
>> noticed I messd up..
>>
>> after that things went good..(from over here sles11.1 sshd looks built
>> fine, maybe this is config issues..,
>> only issue I noticed is getsebool/setsebool are missing, so just do:
>> mv /etc/initscript{,-old}
>> to avoid problems during boot, or define the init_upstart boolean in
>> boolean.conf.)
I set the init_upstart boolean.
>>
>>> which policy did you used?http://oss.tresys.com/git/refpolicy.git?
>>>
>>
>> yep... I follow track
I can't compile the latest refpolicy version from git. make conf results
in: doc/policy.xml:604: element module: validity error : Element module
content does not follow the DTD, expecting (summary , desc? , required? ,
(interface | template)* , (bool | tunable)*), got ()
d

but the latest release from
(http://oss.tresys.com/files/refpolicy/refpolicy-2.20100524.tar.bz2) is
working..
>>
>>> kind regards
>>> Matthias
>>>
>>>
>>
>> Justin P. Mattock
>>
>
> FWIW heres the system info with SELinux and sles11.1:
> http://fpaste.org/hdTI/
>
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

  On 10/26/2010 01:27 AM, imsand@puzzle.ch wrote:
>>    On 10/25/2010 12:57 AM, Justin P. Mattock wrote:
>>> On 10/25/2010 12:09 AM, imsand@puzzle.ch wrote:
>>>> Hi Justin.
>>>>
>>>> First of all, thanks a lot for your efforts.
>>> youre welcome!!
>>>> Unfortunately I'm a little bit confused about what you've done exactly
>>>> to
>>>> make it run.
>>>> Can you please summarize it and make a little step by step guide for
>>>> me?
>>> I can try, but maybe later on another post(a bit late over here.)
>>>> Did selinux worked out of the box (on sles11.1)? Didn't had you have to
>>>> fix the bug in /lib/mkinitrd/scripts/boot-boot.sh and rebuild initrd?
>>> long story short, installed sles11.1, changed the repos to download
>>> git-core
>>> then changed repos to download the rest of the packages to build the
>>> latest Mainline kernel
>>> (make, make modules_install)
> On my installation I took the original kernel, shipped with sles11.1. I
> don't want to compile a new one unless it's strongly recommended. Why
> don't you use the original kernel and packages of sles11.1?

The only way I have access through internet is through the wireless..and 
most distros
dont have my wireless driver...(and of course nvidia module as well for 
a proper looking screen)
so I use a copy of a good revision kernel to get online, pull, then build...

>>> then after that, installed all the SELinux packages, rebooted realized
>>> even though this system is
>>> using sysvinit the policy still wont load without an initrd(must be
>>> because my other systems have
>>> _nothing_ of the sort with initrd in them(*.h)or something, so ended
>>> up using mkinitrd_setup to make the image
>>> so the policy can load..
>>>
> Okey. I also had to rebuild initrd with the adjustments I already described.

cool... yeah you need the image, or else the policy will not load
>>> Then once loaded made sure the home directory was labelled correctly,
>>> as well as other
>>> areas that I've seen issues with, then just started the sshd..with the
>>> other machine with SELinux,
>>> and the iphone(touchterm ssh(free))..
>>>
>>>> which package have you build with --with-selinux and the --with-pam?
> I did't rebuild any packages. Do I have to recomple some packages with
> these options? I just took the original versions, shipped with sles 11.1.

I think the sshd package is good, but I did notice I couldnt find 
getsebool/setsebool to change a boolean
(either it's in /usr/share/man or somewhere else)
>>> this was on my cblfs system.. I just built this(all gnome etc..)and
>>> didnt realize that I had
>>> built this wrong until I looked at config.log of the package and
>>> noticed I messd up..
>>>
>>> after that things went good..(from over here sles11.1 sshd looks built
>>> fine, maybe this is config issues..,
>>> only issue I noticed is getsebool/setsebool are missing, so just do:
>>> mv /etc/initscript{,-old}
>>> to avoid problems during boot, or define the init_upstart boolean in
>>> boolean.conf.)
> I set the init_upstart boolean.

yeah but without setsebool you cant change that...(just rename 
/etc/initscript and/or
modify booleans.conf)
>>>> which policy did you used?http://oss.tresys.com/git/refpolicy.git?
>>>>
>>> yep... I follow track
> I can't compile the latest refpolicy version from git. make conf results
> in: doc/policy.xml:604: element module: validity error : Element module
> content does not follow the DTD, expecting (summary , desc? , required? ,
> (interface | template)* , (bool | tunable)*), got ()
> d
>

thats a first I've seen.. I get errors as well something about 
/tmp/seusers etc..
I just delete and pull git until it works..(biggest pain in the a** are 
these compile errors
that dont need to happen)

> but the latest release from
> (http://oss.tresys.com/files/refpolicy/refpolicy-2.20100524.tar.bz2) is
> working..
>>>> kind regards
>>>> Matthias
>>>>
>>>>
>>>

cheers,

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Context settings after ssh login

[Justin P. Mattock]

  hows the status with this? have you made any progreess.. one thing 
I've noticed over here, is if I use the login:
/usr/sbin/semodule login -a -s staff_u justin

sshd seems to default to user_r:user_t*  but if I tweak the login to my 
name and adjust
/etc/selinux/{$policy}/contexts/users/* to my choosen role it works to 
the modified
role(my guesss is it's maybe something with th uuid or something)

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.