issue with SE/Linux - sshd not giving access to /dev/pts/[n]

issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Luke Kenneth Casson Leighton]

hi there,

i have an issue on my newly created Debian/SELinux/unstable system.

i have pam 0.77 se1 installed
ssh            3.8.1p1-4      (OpenSSH)
and libselinux1 1.12-1.

i can log in as root, fine.

but i cannot log in as an ordinary user, and i had to grant
special permission to the _user_ process (NOT sshd or pam
before a setuid and exec is carried out) to access
/dev/pts/0.

in other words, if i understand this correctly, there is a
bug somewhere in either sshd or pam where control of the
tty is given at the wrong point, or is not given at all.

(russell talks of relabelling the tty, i'm not sure what that
would involve.)

... except if the user is root :) :) whereupon magically
it works fiine :)

okay, so does anyone on the openssh or pam lists understand
what this might about?  does it ring any bells?

l.


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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Luke Kenneth Casson Leighton]

On Tue, Jun 01, 2004 at 07:52:29PM +1000, Darren Tucker wrote:
> Luke Kenneth Casson Leighton wrote:
> >but i cannot log in as an ordinary user, and i had to grant
> >special permission to the _user_ process (NOT sshd or pam
> >before a setuid and exec is carried out) to access
> >/dev/pts/0.
> 
> By "user process" do you mean sshd running as the user logging in?  If 
> so, that's probably because of Privilege Separation[1].  Try retesting 
> with "UsePrivilegeSeparation no" in sshd_config.
 
 ah ha!

 let's see.... YEP!  that does it.

 great!

 okay, so now in order to avoid one auditing experience or
 should i say something which requires special permissions to
 be allowed, i have to switch off something that is there for
 security reasons, ho hum.


> When privsep is on, sshd starts running as the user quite early, leaving 
> behind another process (the "monitor") running as root, while the 
> unprivileged sshd does most of the work (network comms, protocol 
> processing, compression and so on).  When the user requests a pty, one 
> is allocated by the monitor (pty allocation is a privileged operation on 
> some platforms) and a descriptor is passed to the unprivileged child 
> (the "slave"), which then forks, makes the pty its controlling tty runs 
> the shell.  This is probably what you're seeing.

 *glurk*...  i actually understood that.

 okay.

 the "expected" behaviour shall we say of the SE/linux auditing rules
 that russell has created is that only the sshd domain (where a
 domain correlates to a process, in this case the "monitor") has
 been given permission to do ioctl and read and write to the
 tty (/dev/pts/NN).

 and the "user" domain, i.e. after a fork() and set(e?)uid() / gid(),
 is most definitely NOT granted permission to read/write to ssh-specific
 ptys because only the sshd domain is allowed that.

 ... russell, et al, is there some way to reflect the above
 into SE/Linux auditing rules?

 l.


> >in other words, if i understand this correctly, there is a
> >bug somewhere in either sshd or pam where control of the
> >tty is given at the wrong point, or is not given at all.
> 
> It's not a bug, it's a Feature.
> 
> [1] http://www.citi.umich.edu/u/provos/ssh/privsep.html

 :)

 ta.

 l.


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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Russell Coker]

On Tue, 1 Jun 2004 19:03, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> i have an issue on my newly created Debian/SELinux/unstable system.
>
> i have pam 0.77 se1 installed
> ssh            3.8.1p1-4      (OpenSSH)
> and libselinux1 1.12-1.
>
> i can log in as root, fine.
>
> but i cannot log in as an ordinary user, and i had to grant
> special permission to the _user_ process (NOT sshd or pam
> before a setuid and exec is carried out) to access
> /dev/pts/0.
>
> in other words, if i understand this correctly, there is a
> bug somewhere in either sshd or pam where control of the
> tty is given at the wrong point, or is not given at all.

When you login the terminal must be given a type label that permits you access 
to it.  Otherwise you can't access your terminal and get logged out.

There is a bug in the SE Linux pam code or in sshd which results in the 
terminal not being correctly relabelled in some situations.  Someone (maybe 
you) needs to debug this.  I would guess that the PAM code is doing the wrong 
thing, the PAM code in question is in Fedora and in my repository for SE 
Linux Debian packages.  It is not in the main-line PAM distribution because 
nothing happens there.

So asking the pam-list is not going to do any good because probably no-one on 
that list has even seen the code in question.  Same goes for the ssh list.

Best to just debug the code yourself.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Stephen Smalley]

On Wed, 2004-06-02 at 02:31, Russell Coker wrote:
> When you login the terminal must be given a type label that permits you access 
> to it.  Otherwise you can't access your terminal and get logged out.
> 
> There is a bug in the SE Linux pam code or in sshd which results in the 
> terminal not being correctly relabelled in some situations.  Someone (maybe 
> you) needs to debug this.  I would guess that the PAM code is doing the wrong 
> thing, the PAM code in question is in Fedora and in my repository for SE 
> Linux Debian packages.  It is not in the main-line PAM distribution because 
> nothing happens there.

I hadn't seen such a bug report previously - is this also true of the
RedHat openssh package (still based on 3.6.1p2) or is it new to 3.8?  If
using pam doesn't work with 3.8 (e.g. if they have moved the call to
pam_open_session such that it is no longer performed at the right point
in processing for us to set the exec context and relabel the pty), then
I would recommend going back to a direct patch for sshd.  The direct
patch for openssh 3.6 (prior to switching to using pam_selinux) is
below.

--- openssh-3.6.1p2/session.c.selinux	2003-10-13 10:22:17.975083901 -0400
+++ openssh-3.6.1p2/session.c	2003-10-13 10:22:34.399253449 -0400
@@ -58,6 +58,11 @@
 #include "session.h"
 #include "monitor_wrap.h"
 
+#ifdef WITH_SELINUX
+#include <selinux/get_context_list.h>
+#include <selinux/selinux.h>
+#endif
+
 #ifdef HAVE_CYGWIN
 #include <windows.h>
 #include <sys/cygwin.h>
@@ -1268,6 +1273,18 @@
 #endif
 	if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid)
 		fatal("Failed to set uids to %u.", (u_int) pw->pw_uid);
+#ifdef WITH_SELINUX
+	if (is_selinux_enabled()>0)
+	  {
+	    security_context_t scontext;
+	    if (get_default_context(pw->pw_name,NULL,&scontext))
+	      fatal("Failed to get default security context for %s.", pw->pw_name);
+	    if (setexeccon(scontext)) {
+	      fatal("Failed to set exec security context %s for %s.", scontext, pw->pw_name);
+	    }
+	    freecon(scontext);
+	  }
+#endif
 }
 
 static void
--- openssh-3.6.1p2/sshpty.c.selinux	2003-02-23 19:54:10.000000000 -0500
+++ openssh-3.6.1p2/sshpty.c	2003-10-13 10:22:18.079072312 -0400
@@ -22,6 +22,12 @@
 #include "log.h"
 #include "misc.h"
 
+#ifdef WITH_SELINUX
+#include <selinux/flask.h>
+#include <selinux/get_context_list.h>
+#include <selinux/selinux.h>
+#endif
+
 /* Pty allocated with _getpty gets broken if we do I_PUSH:es to it. */
 #if defined(HAVE__GETPTY) || defined(HAVE_OPENPTY)
 #undef HAVE_DEV_PTMX
@@ -386,6 +392,37 @@
 	 * Warn but continue if filesystem is read-only and the uids match/
 	 * tty is owned by root.
 	 */
+#ifdef WITH_SELINUX
+	if (is_selinux_enabled()>0) {
+	  security_context_t 	  new_tty_context=NULL,
+	    user_context=NULL, old_tty_context=NULL; 
+
+	  if (get_default_context(pw->pw_name,NULL,&user_context))
+	      fatal("Failed to get default security context for %s.", pw->pw_name);
+
+	  if (getfilecon(ttyname, &old_tty_context)<0) {
+	    error("getfilecon(%.100s) failed: %.100s", ttyname,
+		  strerror(errno));
+	  }
+	  else 
+	    {
+	      if ( security_compute_relabel(user_context,old_tty_context,SECCLASS_CHR_FILE,&new_tty_context)!=0) {
+		error("security_compute_relabel(%.100s) failed: %.100s", ttyname,
+		      strerror(errno));
+	      } 
+	      else 
+		{
+		  if (setfilecon (ttyname, new_tty_context) != 0) {
+		    error("setfilecon(%.100s, %s) failed: %.100s",
+			  ttyname, new_tty_context, strerror(errno));
+		  }
+		  freecon(new_tty_context);
+		}
+	      freecon(old_tty_context);
+	    }
+	  freecon(user_context);
+	}
+#endif
 	if (stat(ttyname, &st))
 		fatal("stat(%.100s) failed: %.100s", ttyname,
 		    strerror(errno));
@@ -415,4 +452,5 @@
 				    ttyname, mode, strerror(errno));
 		}
 	}
+
 }
--- openssh-3.6.1p2/Makefile.in.selinux	2003-04-29 05:12:08.000000000 -0400
+++ openssh-3.6.1p2/Makefile.in	2003-10-13 10:22:18.080072200 -0400
@@ -40,7 +40,7 @@
 
 CC=@CC@
 LD=@LD@
-CFLAGS=@CFLAGS@
+CFLAGS=@CFLAGS@ -DWITH_SELINUX
 CPPFLAGS=-I. -I$(srcdir) @CPPFLAGS@ $(PATHS) @DEFS@
 LIBS=@LIBS@
 LIBPAM=@LIBPAM@
@@ -52,7 +52,7 @@
 SED=@SED@
 ENT=@ENT@
 XAUTH_PATH=@XAUTH_PATH@
-LDFLAGS=-L. -Lopenbsd-compat/ @LDFLAGS@
+LDFLAGS=-L. -Lopenbsd-compat/ @LDFLAGS@ -lselinux 
 EXEEXT=@EXEEXT@
 
 INSTALL_SSH_PRNG_CMDS=@INSTALL_SSH_PRNG_CMDS@

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Russell Coker]

On Thu, 3 Jun 2004 03:23, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > There is a bug in the SE Linux pam code or in sshd which results in the
> > terminal not being correctly relabelled in some situations.  Someone
> > (maybe you) needs to debug this.  I would guess that the PAM code is
> > doing the wrong thing, the PAM code in question is in Fedora and in my
> > repository for SE Linux Debian packages.  It is not in the main-line PAM
> > distribution because nothing happens there.
>
> I hadn't seen such a bug report previously - is this also true of the
> RedHat openssh package (still based on 3.6.1p2) or is it new to 3.8?  If
> using pam doesn't work with 3.8 (e.g. if they have moved the call to
> pam_open_session such that it is no longer performed at the right point
> in processing for us to set the exec context and relabel the pty), then

I don't think it occurred on 3.6.x.  It occurs on both Fedora and Debian, but 
does not always happen.  I'm not sure of the exact cause.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Stephen Smalley]

On Thu, 2004-06-03 at 00:04, Russell Coker wrote:
> I don't think it occurred on 3.6.x.  It occurs on both Fedora and Debian, but 
> does not always happen.  I'm not sure of the exact cause.

Fedora is still using openssh 3.6.  Are you sure it occurs on Fedora?

In any event, looking briefly at 3.6 vs. 3.8, I see that:
1) in 3.6, session.c:do_exec_pty() calls do_pam_session() with the
username and tty.  auth-pam.c:do_pam_session() then sets PAM_TTY prior
to calling pam_open_sesson(), so the tty is available to pam_selinux for
relabeling.
2) in 3.8, session.c:do_setusercontext() calls do_pam_session() with no
arguments, and auth-pam.c:do_pam_session() calls pam_open_session()
without setting PAM_TTY (as no information is available at this point),
so pam_selinux lacks the tty information.  
The implication is that pam_selinux cannot perform tty relabeling for
openssh 3.8.  Thus, we must revert to using a direct patch.  Someone
want to port the old 3.6 patch?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Stephen Smalley]

On Thu, 2004-06-03 at 08:41, Stephen Smalley wrote:
> Fedora is still using openssh 3.6.  Are you sure it occurs on Fedora?
> 
> In any event, looking briefly at 3.6 vs. 3.8, I see that:
> 1) in 3.6, session.c:do_exec_pty() calls do_pam_session() with the
> username and tty.  auth-pam.c:do_pam_session() then sets PAM_TTY prior
> to calling pam_open_sesson(), so the tty is available to pam_selinux for
> relabeling.
> 2) in 3.8, session.c:do_setusercontext() calls do_pam_session() with no
> arguments, and auth-pam.c:do_pam_session() calls pam_open_session()
> without setting PAM_TTY (as no information is available at this point),
> so pam_selinux lacks the tty information.  
> The implication is that pam_selinux cannot perform tty relabeling for
> openssh 3.8.  Thus, we must revert to using a direct patch.  Someone
> want to port the old 3.6 patch?

BTW, note that the patch is very simple; you just want to extend the
existing code that sets the user identity to also set the exec context,
and you want to extend the existing code that changes the ownership of
the pty to also set the context on the pty.  The advantage of a direct
patch is that we can precisely parallel the existing code, whereas
pam_selinux isn't necessarily called at the same point.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Russell Coker]

On Thu, 3 Jun 2004 23:14, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > The implication is that pam_selinux cannot perform tty relabeling for
> > openssh 3.8.  Thus, we must revert to using a direct patch.  Someone
> > want to port the old 3.6 patch?
>
> BTW, note that the patch is very simple; you just want to extend the

It seems to me that pam_selinux is not going to do what we want.

We have to split the module into two parts to get the desired behaviour.  It 
doesn't work with sshd, and some xdm's.  Now it only works with /bin/login 
and one xdm variant (AFAIK).

I think that we are taking the wrong approach to this and we should give up 
and just patch the applications?


Dan, as inventor of the pam_selinux module, what do you think?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Stephen Smalley]

On Fri, 2004-06-04 at 07:32, Russell Coker wrote:
> It seems to me that pam_selinux is not going to do what we want.
> 
> We have to split the module into two parts to get the desired behaviour.

For people who haven't followed that discussion (started on
fedora-selinux-list), the issue is that pam_selinux can have side
effects on other pam session modules in the pam stack (since it sets the
exec context for the user and relabels the pty/tty), so it needs to run
last upon pam_open_session and first upon pam_close_session.  The only
way to ensure that ordering is to split pam_selinux into two pam modules
(which can be achieved logically just by introducing a module argument
to indicate the desired behavior, which is what Dan is implementing),
one for open_session and one for close_session, and bracket the pam
stack with the two entries.

>   It 
> doesn't work with sshd, and some xdm's.  Now it only works with /bin/login 
> and one xdm variant (AFAIK).

It also works for /bin/su, although even in that case, there was a
problem (inability to re-open tty since fsuid has already been changed
by su) that resulted in dropping the re-opening of stdin/out/err by
pam_selinux to get the descriptors into the right type.

> I think that we are taking the wrong approach to this and we should give up 
> and just patch the applications?

Quite possibly.  An alternative would be to continue using pam_selinux
for setting the exec context for sshd but add a patch for relabeling the
pty, and just pass the nottys option to pam_selinux in the sshd pam
configuration to disable the tty relabeling for it.  This would still
require bracketing the pam stack with the close_session and open_session
cases to avoid side effects.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Daniel J Walsh]

Russell Coker wrote:

>On Thu, 3 Jun 2004 23:14, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
>  
>
>>>The implication is that pam_selinux cannot perform tty relabeling for
>>>openssh 3.8.  Thus, we must revert to using a direct patch.  Someone
>>>want to port the old 3.6 patch?
>>>      
>>>
>>BTW, note that the patch is very simple; you just want to extend the
>>    
>>
>
>It seems to me that pam_selinux is not going to do what we want.
>
>We have to split the module into two parts to get the desired behaviour.  It 
>doesn't work with sshd, and some xdm's.  Now it only works with /bin/login 
>and one xdm variant (AFAIK).
>
>I think that we are taking the wrong approach to this and we should give up 
>and just patch the applications?
>
>
>Dan, as inventor of the pam_selinux module, what do you think?
>
>  
>
openssh has been repatched with the old patch.  Basically openssh 3.8 
has this kind of pseudo code.

Authenticate
If UID != 0
       pam_open_session
       Drop Creds
Alloc TTY
IF UID == 0
       pam_open_session
Exec shell

This causes the stange behavior where if you ssh in to root, pam_selinux 
works correctly.
If you ssh as a normal user pam_selinux does not relabel the tty and you 
get connection dropped.

After investigating how we could get this behavior changed we decided to 
just patch openssh with the setexec and tty relabel, and drop 
pam_selinux from /etc/pam.d/sshd

As far as dropping pam_selinux, I don't think that is a good idea since 
it can be used by third party apps that might want this behavior and it 
works fairly well for su and login.

Dan


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

Re: issue with SE/Linux - sshd not giving access to /dev/pts/[n]

[Russell Coker]

On Thu, 10 Jun 2004 03:21, Daniel J Walsh <dwalsh@redhat.com> wrote:
> openssh has been repatched with the old patch.  Basically openssh 3.8
> has this kind of pseudo code.
>
> Authenticate
> If UID != 0
>        pam_open_session
>        Drop Creds
> Alloc TTY
> IF UID == 0
>        pam_open_session
> Exec shell
>
> After investigating how we could get this behavior changed we decided to
> just patch openssh with the setexec and tty relabel, and drop
> pam_selinux from /etc/pam.d/sshd

OK.

Another thing, I think it would be good if we could have sshd drop creds for 
uid == 0 as well.  On a SE Linux system there is no guarantee that uid 0 has 
administrative privs, and having multiple code paths does not seem to be a 
benefit for security.  When I was last maintaining a patched sshd I did that, 
it was a couple of extra lines of code that seemed to be useful.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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