On 28/09/10 08:24, imsand@puzzle.ch 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@lists.fedoraproject.org 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?

On Tue, Sep 28, 2010 at 01:56:13PM +0200, imsand@puzzle.ch wrote:

...

...

On 28/09/10 08:24, imsand@puzzle.ch 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@lists.fedoraproject.org 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.

...

--

Yeah, setting init_upstart to on did the trick! THANK A LOT! Do you know why this prevents the user from logging in through ssh even if selinux is set to permissive??

On 28/09/10 15:08, Daniel J Walsh wrote:

...

...

...

...

...

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.

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.

Yeah, setting init_upstart to on did the trick! THANK A LOT! Do you know why this prevents the user from logging in through ssh even if selinux is set to permissive??

Probably a bug in pam_selinux or sshd if it does not use pam_selinux. Something is not respecting the permissive mode flag. Of course you are asking about sles on the Fedora mailing list.. :^)

You'd see the same problem in Fedora if sshd wasn't running in sshd_t. The SSH server tries to compute the correct context for the session, fails, and bails out even in permissive mode. I saw this happen in the curl test suite, where we start an SSH server and try connecting to it.

Paul.

On 28/09/10 16:10, imsand@puzzle.ch wrote:

...

On 28/09/10 15:08, Daniel J Walsh wrote:

...

...

...

...

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

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.

Yeah, setting init_upstart to on did the trick! THANK A LOT! Do you know why this prevents the user from logging in through ssh even if selinux is set to permissive??

Probably a bug in pam_selinux or sshd if it does not use pam_selinux. Something is not respecting the permissive mode flag. Of course you are asking about sles on the Fedora mailing list.. :^)

You'd see the same problem in Fedora if sshd wasn't running in sshd_t. The SSH server tries to compute the correct context for the session, fails, and bails out even in permissive mode. I saw this happen in the curl test suite, where we start an SSH server and try connecting to it.

Paul.

After setting init_upstart = on sshd runs in sshd_t. Do you know why? Can't sshd do a domain transition if init_upstart is disabled?

There's more on this here:

https://bugzilla.novell.com/show_bug.cgi?id=582399

Paul.

...

On 28/09/10 16:10, imsand@puzzle.ch wrote:

...

...

On 28/09/10 15:08, Daniel J Walsh wrote:

...

...

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

Yeah, setting init_upstart to on did the trick! THANK A LOT! Do you know why this prevents the user from logging in through ssh even if selinux is set to permissive??

Probably a bug in pam_selinux or sshd if it does not use pam_selinux. Something is not respecting the permissive mode flag. Of course you are asking about sles on the Fedora mailing list.. :^)

You'd see the same problem in Fedora if sshd wasn't running in sshd_t. The SSH server tries to compute the correct context for the session, fails, and bails out even in permissive mode. I saw this happen in the curl test suite, where we start an SSH server and try connecting to it.

Paul.

After setting init_upstart = on sshd runs in sshd_t. Do you know why? Can't sshd do a domain transition if init_upstart is disabled?

There's more on this here:

https://bugzilla.novell.com/show_bug.cgi?id=582399

Paul.

Thank you for the link. I rename "/etc/initscript" like described it the report. now, sshing is working in both cases (init_upstart = on | off). Thats fine. But the role transition still not work.

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

I found out that the role transition works when the linux user name is equivalent to the SELinux name (both are mat_u). If so, the default user context after login via ssh is: "context=mat_u:staff_r:staff_t" And the explicit role transition to sysadm_r works as desired: "newrole -r sysadm_r" results in "context=mat_u:sysadm_r:sysadm_t".

So far as I see, the user mapping seems to be correct: semanage login -l | grep mat Login Name SELinux User mat mat_u

When I rename the Linux Login name back to mat, the role transition don't work anymore and the SELinux context switches back to "user_u:user_r:user_t" which is the default context if no correspond user is found by SELinux.

Do I miss something?

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

On 09/30/2010 07:37 AM, imsand@puzzle.ch wrote:

...

...

...

On 28/09/10 16:10, imsand@puzzle.ch wrote:

...

...

On 28/09/10 15:08, Daniel J Walsh wrote: >>>>>> 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. >>>>> >>>> >>>> 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. >> >> Yeah, setting init_upstart to on did the trick! THANK A LOT! >> Do you know why this prevents the user from logging in through ssh >> even >> if >> selinux is set to permissive?? >> > Probably a bug in pam_selinux or sshd if it does not use > pam_selinux. > Something is not respecting the permissive mode flag. Of course > you > are > asking about sles on the Fedora mailing list.. :^)

You'd see the same problem in Fedora if sshd wasn't running in sshd_t. The SSH server tries to compute the correct context for the session, fails, and bails out even in permissive mode. I saw this happen in the curl test suite, where we start an SSH server and try connecting to it.

Paul.

After setting init_upstart = on sshd runs in sshd_t. Do you know why? Can't sshd do a domain transition if init_upstart is disabled?

There's more on this here:

https://bugzilla.novell.com/show_bug.cgi?id=582399

Paul.

Thank you for the link. I rename "/etc/initscript" like described it the report. now, sshing is working in both cases (init_upstart = on | off). Thats fine. But the role transition still not work.

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

I found out that the role transition works when the linux user name is equivalent to the SELinux name (both are mat_u). If so, the default user context after login via ssh is: "context=mat_u:staff_r:staff_t" And the explicit role transition to sysadm_r works as desired: "newrole -r sysadm_r" results in "context=mat_u:sysadm_r:sysadm_t".

So far as I see, the user mapping seems to be correct: semanage login -l | grep mat Login Name SELinux User mat mat_u

When I rename the Linux Login name back to mat, the role transition don't work anymore and the SELinux context switches back to "user_u:user_r:user_t" which is the default context if no correspond user is found by SELinux.

Do I miss something?

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

Are you the guy on SLES? Or Fedora? In the old days pam_selinux and libselinux used to not map Linux Users to SELinux users. So you had to create a SELinux user for every user. You may be using an older version of the code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkykhQQACgkQrlYvE4MpobPJrACfS0V70jI598DSZVQFAMrppJKR oR4An1emGUteIRfmKNzN9wP0FFUdX+TY =HWJA -----END PGP SIGNATURE-----

I'm using sles11sp1. I know, this is a fedora list but maybe thats a common problem or a missunderstanding of something which is not related to the distribution... I'm using libselinux1-2.0.91-4.2.1 and pam-1.0.4-0.5.12. It seems that they are quite new and adopted from fedora (especially the man page of pam_selinux which is from 12/18/2009 and written you ;)) How can I verify if it's a problem of a too old libselinux or pam_selinux version?

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

On 09/30/2010 10:18 AM, imsand@puzzle.ch wrote:

another interesting thing is the following: (seen with the debug option in pam_selinux)

assuming that the linux user is mat and the corresponding selinux user is mat_u. during ssh login this happens:

Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): Open Session Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): Open Session Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): Username= mat SELinux User = mat_u Level= (null) Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): set mat security context to mat_u:staff_r:staff_t Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): set mat key creation context to mat_u:staff_r:staff_t

As we can see, the user mapping works as desired and the new choosen context should be all right => mat_u:staff_r:staff_t.

But then, when I do an id -Z after successful login, the shell's context is context=user_u:user_r:user_t.

Very strange....

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

You got me. If you create the mat_u user and login does the pam_selinux session look different?

Why don't you ask on the upstream selinux list. More sles experience is probably there that is not monitoring this list. selinux@tycho.nsa.gov

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

On 10/01/2010 03:52 AM, Matthias Imsand wrote:

On 09/30/2010 08:24 PM, Daniel J Walsh wrote:

...

On 09/30/2010 10:18 AM, imsand@puzzle.ch wrote:

...

another interesting thing is the following: (seen with the debug option in pam_selinux)

...

...

assuming that the linux user is mat and the corresponding selinux user is mat_u. during ssh login this happens:

...

...

Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): Open Session Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): Open Session Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): Username= mat SELinux User = mat_u Level= (null) Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): set mat security context to mat_u:staff_r:staff_t Sep 30 16:09:49 testsrv sshd[4328]: pam_selinux(sshd:session): set mat key creation context to mat_u:staff_r:staff_t

...

...

As we can see, the user mapping works as desired and the new choosen context should be all right => mat_u:staff_r:staff_t.

...

...

But then, when I do an id -Z after successful login, the shell's context is context=user_u:user_r:user_t.

...

...

Very strange....

...

...

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

...

You got me. If you create the mat_u user and login does the pam_selinux session look different?

...

Why don't you ask on the upstream selinux list. More sles experience is probably there that is not monitoring this list. selinux@tycho.nsa.gov

no, with mat_u it looks similar. Username= mat_u SELinux User = mat_u Level= (null)

Do you know which library / process is responsible for actually changing the context to mat_u:staff_r:staff_t? Or should it be done directly by the pam_selinux.so?

Yes, tank you for the recommendation. I will ask on that list as well..

- -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

These functions are all called in pam_selinux including

getseuserbyname(const char *linuxuser, char **seuser, char **level);

And setexeccon.

One thing of not is the default user is user_u which seems to be what you are seeing.

On Tue, Sep 28, 2010 at 03:51:11PM +0200, imsand@puzzle.ch wrote:

...

On Tue, Sep 28, 2010 at 01:56:13PM +0200, imsand@puzzle.ch wrote:

...

...

On 28/09/10 08:24, imsand@puzzle.ch 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@lists.fedoraproject.org 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...

...

...

--

Yeah, setting init_upstart to on did the trick! THANK A LOT! Do you know why this prevents the user from logging in through ssh even if selinux is set to permissive??

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

On Wed, Sep 29, 2010 at 09:26:26AM +0200, imsand@puzzle.ch wrote:

...

On Tue, Sep 28, 2010 at 03:51:11PM +0200, imsand@puzzle.ch wrote:

...

...

On Tue, Sep 28, 2010 at 01:56:13PM +0200, imsand@puzzle.ch wrote:

...

...

On 28/09/10 08:24, imsand@puzzle.ch 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@lists.fedoraproject.org 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

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

On Wed, Sep 29, 2010 at 09:50:40AM +0200, imsand@puzzle.ch wrote:

...

On Wed, Sep 29, 2010 at 09:26:26AM +0200, imsand@puzzle.ch wrote:

...

...

On Tue, Sep 28, 2010 at 03:51:11PM +0200, imsand@puzzle.ch wrote:

...

...

On Tue, Sep 28, 2010 at 01:56:13PM +0200, imsand@puzzle.ch wrote: > > On 28/09/10 08:24, imsand@puzzle.ch 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@lists.fedoraproject.org > > 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.

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

On Wed, Sep 29, 2010 at 12:06:23PM +0200, imsand@puzzle.ch wrote:

...

On Wed, Sep 29, 2010 at 09:50:40AM +0200, imsand@puzzle.ch wrote:

...

...

On Wed, Sep 29, 2010 at 09:26:26AM +0200, imsand@puzzle.ch wrote:

...

...

On Tue, Sep 28, 2010 at 03:51:11PM +0200, imsand@puzzle.ch wrote: > > On Tue, Sep 28, 2010 at 01:56:13PM +0200, imsand@puzzle.ch

wrote:

...

...

...

> >> > On 28/09/10 08:24, imsand@puzzle.ch 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@lists.fedoraproject.org > >> > 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

Like i said before:

The combination of user_u with anything other than user_* is invalid user_u is not designed to role transition. only user_u:user_r:user_t is valid

You need to figure out how you can login as staff_u. Meaning that when you login and do id -Z, it returns: staff_u:staff_r:staff_t

When that works, you can as staff role transition to sysadm_r role.

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

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

On 09/29/2010 08:23 AM, Daniel J Walsh wrote:

On 09/29/2010 03:26 AM, imsand@puzzle.ch wrote:

...

...

On Tue, Sep 28, 2010 at 03:51:11PM +0200, imsand@puzzle.ch wrote:

...

...

On Tue, Sep 28, 2010 at 01:56:13PM +0200, imsand@puzzle.ch wrote:

...

> On 28/09/10 08:24, imsand@puzzle.ch 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@lists.fedoraproject.org > 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?

...

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

semanage login -l

- -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

What does

selinuxdefcon mat system_u:system_r:sshd_t:s0

show

selinuxdefcon dwalsh system_u:system_r:sshd_t:s0

staff_u:staff_r:staff_t:s0-s0:c0.c1023

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

On 09/29/2010 09:33 AM, imsand@puzzle.ch wrote:

...

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

On 09/29/2010 08:23 AM, Daniel J Walsh wrote:

...

On 09/29/2010 03:26 AM, imsand@puzzle.ch wrote:

...

...

On Tue, Sep 28, 2010 at 03:51:11PM +0200, imsand@puzzle.ch wrote:

...

> On Tue, Sep 28, 2010 at 01:56:13PM +0200, imsand@puzzle.ch wrote: >>> On 28/09/10 08:24, imsand@puzzle.ch 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@lists.fedoraproject.org >>> 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?

...

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

semanage login -l

---

selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

What does

...

selinuxdefcon mat system_u:system_r:sshd_t:s0

show

...

selinuxdefcon dwalsh system_u:system_r:sshd_t:s0

staff_u:staff_r:staff_t:s0-s0:c0.c1023

selinuxdefcon mat system_u:system_r:sshd_t mat_u:staff_r:staff_t

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

So if you ssh to the box now you should end up with staff_t, which is what you want.

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

On 09/29/2010 10:36 AM, imsand@puzzle.ch wrote:

On 09/29/2010 09:33 AM, imsand@puzzle.ch wrote:

...

...

...

...

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

On 09/29/2010 08:23 AM, Daniel J Walsh wrote:

...

On 09/29/2010 03:26 AM, imsand@puzzle.ch wrote: >> On Tue, Sep 28, 2010 at 03:51:11PM +0200, imsand@puzzle.ch wrote: >>>> On Tue, Sep 28, 2010 at 01:56:13PM +0200, imsand@puzzle.ch wrote: >>>>>> On 28/09/10 08:24, imsand@puzzle.ch 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@lists.fedoraproject.org >>>>>> 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?

> -- > selinux mailing list > selinux@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/selinux

semanage login -l

---

selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

What does

...

selinuxdefcon mat system_u:system_r:sshd_t:s0

show

...

selinuxdefcon dwalsh system_u:system_r:sshd_t:s0

staff_u:staff_r:staff_t:s0-s0:c0.c1023

selinuxdefcon mat system_u:system_r:sshd_t mat_u:staff_r:staff_t

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

So if you ssh to the box now you should end up with staff_t, which is what you want.

...

No, unfortunately not and thats the curious thing about that. I still end up with user_r.

Please have a look at this:

root@localhost: ssh mat@stvlx05 Password: ******** mat@testsrv:~> id uid=6575(mat) gid=100(users) groups=16(dialout),33(video),100(users) context=user_u:user_r:user_t mat@testsrv:~> sudo /usr/sbin/selinuxdefcon mat system_u:system_r:sshd_t mat_u:staff_r:staff_tmat@testsrv:~>

---

the user's role is user_r even it should be staff_r. !?!?

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

What context is sshd running as?

ps -eZ | grep sshd