All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Justin P. Mattock" <justinmattock@gmail.com>
To: imsand@puzzle.ch
Cc: selinux@tycho.nsa.gov, sds@tycho.nsa.gov,
	Dominick Grift <domg472@gmail.com>,
	Chris PeBenito <pebenito@gentoo.org>,
	refpolicy@oss1.tresys.com
Subject: Re: Context settings after ssh login
Date: Wed, 06 Oct 2010 06:50:37 -0700	[thread overview]
Message-ID: <4CAC7EAD.7080509@gmail.com> (raw)
In-Reply-To: <15078.193.5.216.100.1286350177.squirrel@mail.puzzle.ch>

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.

WARNING: multiple messages have this Message-ID (diff)
From: justinmattock@gmail.com (Justin P. Mattock)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Context settings after ssh login
Date: Wed, 06 Oct 2010 06:50:37 -0700	[thread overview]
Message-ID: <4CAC7EAD.7080509@gmail.com> (raw)
In-Reply-To: <15078.193.5.216.100.1286350177.squirrel@mail.puzzle.ch>

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

  reply	other threads:[~2010-10-06 13:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-04  8:03 Context settings after ssh login imsand
2010-10-04 17:13 ` Justin P. Mattock
2010-10-05  6:30   ` imsand
2010-10-05 13:29     ` Justin P. Mattock
2010-10-05 13:38       ` imsand
2010-10-05 14:29         ` Justin P. Mattock
2010-10-06  6:43           ` imsand
2010-10-06  7:06             ` Justin P. Mattock
2010-10-06  7:29               ` imsand
2010-10-06 13:50                 ` Justin P. Mattock [this message]
2010-10-06 13:50                   ` [refpolicy] " Justin P. Mattock
2010-10-07 14:40                 ` Chad Sellers
2010-10-07 16:11                   ` Daniel J Walsh
2010-10-07 17:24                     ` Justin P. Mattock
2010-10-19 14:42                       ` imsand
2010-10-19 14:55                         ` Justin P. Mattock
2010-10-19 15:47                           ` imsand
2010-10-19 16:38                             ` Justin P. Mattock
2010-10-20  8:42                               ` imsand
2010-10-20 12:27                                 ` Daniel J Walsh
2010-10-20 13:46                                 ` Justin P. Mattock
2010-10-20 14:25                                   ` imsand
2010-10-20 14:52                                     ` Justin P. Mattock
2010-10-21 12:09                                       ` imsand
2010-10-21 13:33                                         ` Justin P. Mattock
2010-10-24 23:43                                         ` Russell Coker
2010-10-23  6:28                                     ` Justin P. Mattock
2010-10-23 20:05                                     ` Justin P. Mattock
2010-10-25  7:09                                       ` imsand
2010-10-25  7:57                                         ` Justin P. Mattock
2010-10-25  8:22                                           ` Justin P. Mattock
2010-10-26  8:27                                             ` imsand
2010-10-26 14:26                                               ` Justin P. Mattock
2010-10-28 13:23                                               ` Justin P. Mattock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CAC7EAD.7080509@gmail.com \
    --to=justinmattock@gmail.com \
    --cc=domg472@gmail.com \
    --cc=imsand@puzzle.ch \
    --cc=pebenito@gentoo.org \
    --cc=refpolicy@oss1.tresys.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.