Re: Context settings after ssh login

["Justin P. Mattock" <justinmattock@gmail.com>]

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.