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.