> On Wed, Sep 29, 2010 at 09:50:40AM +0200, imsand@xxxxxxxxx wrote:
>> > On Wed, Sep 29, 2010 at 09:26:26AM +0200, imsand@xxxxxxxxx wrote:
>> >> > On Tue, Sep 28, 2010 at 03:51:11PM +0200, imsand@xxxxxxxxx wrote:
>> >> >> > On Tue, Sep 28, 2010 at 01:56:13PM +0200, imsand@xxxxxxxxx
>> wrote:
>> >> >> >> > On 28/09/10 08:24, imsand@xxxxxxxxx wrote:
>> >> >> >> >> Hello
>> >> >> >> >>
>> >> >> >> >> I get the following error when I try to log in through ssh
>> >> (even
>> >> >> if
>> >> >> >> >> selinux is in permissive mode!!!):
>> >> >> >> >>
>> >> >> >> >> Sep 28 09:01:32 stvlx05.test.ch sshd[12614]: Accepted
>> >> >> >> >> keyboard-interactive/pam for mat from 131.102.233.127 port
>> >> 58912
>> >> >> ssh2
>> >> >> >> >> Sep 28 09:01:32 stvlx05.test.admin.ch kernel: [60557.252750]
>> >> >> >> type=1400
>> >> >> >> >> audit(1285657292.298:286): avc: denied { audit_control }
>> for
>> >> >> >> >> pid=12614
>> >> >> >> >> comm="sshd" capability=30
>> scontext=system_u:system_r:sysadm_t
>> >> >> >> >> tcontext=system_u:system_r:sysadm_t tclass=capability
>> >> >> >> >> Sep 28 09:01:32 stvlx05.test.ch sshd[12621]: error:
>> >> >> >> >> ssh_selinux_getctxbyname: Failed to get default SELinux
>> >> security
>> >> >> >> context
>> >> >> >> >> for mat
>> >> >> >> >> Sep 28 09:01:32 stvlx05.test.ch sshd[12614]: error:
>> >> >> >> >> ssh_selinux_getctxbyname: Failed to get default SELinux
>> >> security
>> >> >> >> context
>> >> >> >> >> for mat
>> >> >> >> >> Sep 28 09:01:32 stvlx05.test.ch sshd[12614]: error:
>> >> >> >> >> ssh_selinux_setup_pty:
>> >> >> >> >> security_compute_relabel: Invalid argument
>> >> >> >> >>
>> >> >> >> >> I already went through this post:
>> >> >> >> >> http://www.nsa.gov/research/selinux/list-archive/0910/30906.shtml
>> >> >> but
>> >> >> >> I
>> >> >> >> >> can't figure out the exact problem.
>> >> >> >> >>
>> >> >> >> >> Here is what I've done so far:
>> >> >> >> >> - Downloaded the latest reference policy from tresys:
>> >> >> >> >> http://oss.tresys.com/files/refpolicy/refpolicy-2.20100524.tar.bz2
>> >> >> >> >> - Compiled and installed it on my sles 11.1
>> >> >> >> >> - set selinux into permissive mode: (so far so good.. :))
>> >> >> >> >> sestatus
>> >> >> >> >> SELinux status: enabled
>> >> >> >> >> SELinuxfs mount: /selinux
>> >> >> >> >> Current mode: permissive
>> >> >> >> >> Mode from config file: permissive
>> >> >> >> >> Policy version: 24
>> >> >> >> >> Policy from config file: refpolicy
>> >> >> >> >> - 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
>> >> >> >> (don't
>> >> >> >> >> know if that's needed??!): cp
>> >> >> >> >> /etc/selinux/refpolicy/contexts/user/staff_u
>> >> >> >> >> /etc/selinux/refpolicy/contexts/user/mat_u
>> >> >> >> >> - set boolean for sysadm ssh login to true (don't know if
>> thats
>> >> >> >> >> needed?!):
>> >> >> >> >> setsebool ssh_sysadm_login on
>> >> >> >> >>
>> >> >> >> >> In other posts I've read something about sepermit.conf and
>> >> >> >> >> namespace.conf
>> >> >> >> >> but these files don't exist on my system. What about these
>> >> files?
>> >> >> Do
>> >> >> >> I
>> >> >> >> >> need them?
>> >> >> >> >> What's wrong on my system?
>> >> >> >> >> Why it's not possible to login even if selinux is in
>> permissive
>> >> >> mode?
>> >> >> >> >> Any suggestions?
>> >> >> >> >
>> >> >> >> > I'd start by trying to figure out why sshd isn't running in
>> >> sshd_t
>> >> >> (it
>> >> >> >> > seems to be running in sysadm_t).
>> >> >> >> >
>> >> >> >> > Paul.
>> >> >> >> > --
>> >> >> >> > selinux mailing list
>> >> >> >> > selinux@xxxxxxxxxxxxxxxxxxxxxxx
>> >> >> >> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>> >> >> >> >
>> >> >> >>
>> >> >> >> Yes, sshd is running in sysadm_t:
>> >> >> >>
>> >> >> >> # ps axZ | grep sshd
>> >> >> >> system_u:system_r:sysadm_t 3632 ? Ss 0:00
>> >> >> >> /usr/sbin/sshd
>> >> >> >> -o PidFile=/var/run/sshd.init.pi
>> >> >> >>
>> >> >> >> # ls -Z /usr/sbin/sshd
>> >> >> >> system_u:object_r:sshd_exec_t /usr/sbin/sshd
>> >> >> >>
>> >> >> >> Don't know why it's not sshd_t. I didn't modified something.
>> It's
>> >> a
>> >> >> >> standard installation of sles11 with the default reference
>> policy
>> >> >> from
>> >> >> >> tresys.
>> >> >> >>
>> >> >> >> Maybe this code snippet from policy/modules/services/ssh.te is
>> >> >> >> responsible
>> >> >> >> for that:
>> >> >> >> ## <desc>
>> >> >> >> ## <p>
>> >> >> >> ## Allow ssh logins as sysadm_r:sysadm_t
>> >> >> >> ## </p>
>> >> >> >> ## </desc>
>> >> >> >> gen_tunable(ssh_sysadm_login, true)
>> >> >> >>
>> >> >> >> Any ideas?
>> >> >> >
>> >> >> > Do you have boolean init_upstart set to on? if not try setting
>> it
>> >> to
>> >> >> on.
>> >> >> > I do not believe ssh_sysadm_login boolean works currently but i
>> may
>> >> be
>> >> >> > mistaken.
>> >> >
>> >> > ssh_sysadm_login DOES actually work you just need to specify your
>> role
>> >> on
>> >> > login...
>> >> >
>> >> I suppose to edit
>> /etc/selinux/refpolicy/src/policy/config/local.users
>> >> for
>> >> doing so!? I added "user mat roles { sysadm_r };" rebuild & load the
>> >> policy. But after login the the context is still
>> "user_u:user_r:user_t".
>> >> the user should be able to change the role to sysadm_r:
>> >> ----
>> >> semanage user -l
>> >> SELinux User SELinux Roles
>> >> mat_u staff_r sysadm_r
>> >> ----
>> >> Doing it explicitly does not work either:
>> >> ----
>> >> newrole -r staff_r
>> >> user_u:staff_r:staff_t is not a valid context
>> >> ----
>> >> Don't know why. Restricted by a special policy?
>> >
>> > Yes restricted by constraints. user_u is designed to not be allowed to
>> > role transition.
>> > First you much achieve that you login with the staff_u identity (and
>> > staff_r role, staff_t domain)
>> >
>> > I am not sure why youre login identity is user_u and not staff_u. Have
>> > you:
>> >
>> > semanage login -a -s mat_u mat
>> > semanage login -l | grep mat
>> >>
>> >>
>>
>> Yes, I have. mat is mapped to mat_u.
>> semanage login -l | grep mat
>> mat mat_u
>
> Assuming that you have a mat_u file with staff contexts in
> /etc/selinux/targeted/context/users, my first guess would be that you have
> some pam_selinux issues.
>
mat_u users file looks like this:
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
I'm not sure about the pam configuration. I tried like this:
cat /etc/pam.d/login
#%PAM-1.0
auth requisite pam_nologin.so
auth [user_unknown=ignore success=ok ignore=ignore auth_err=die
default=bad] pam_securetty.so
auth include common-auth
account include common-account
password include common-password
session required pam_selinux.so close
session required pam_selinux.so open
session required pam_loginuid.so
session include common-session
session required pam_lastlog.so nowtmp
session optional pam_mail.so standard
session optional pam_ck_connector.so
vim /etc/pam.d/sshd
#%PAM-1.0
auth requisite pam_nologin.so
auth include common-auth
account include common-account
password include common-password
session required pam_selinux.so close
session required pam_selinux.so open
session required pam_loginuid.so
session include common-sessi
but still no luck.
mat@localhost:~> newrole -r staff_r
user_u:staff_r:staff_t is not a valid context
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
