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

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.

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.

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

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On Tue, 1 Jun 2004 19:03, Luke Kenneth Casson Leighton <lkcl at 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