Privilege Separation Design Question

[Eric Anderle]

Hello Damien,

Thank you for your reply. Here at CITI, we have a security requirement
that forces users to reauthenticate with SSH periodically, even if there
is activity on the connection. We are using getpwnamallow() to ensure
that the user is still authorized to use the system (e.g., /etc/passwd
hasn't been modified or something like that). Our code enables the
MONITOR_REQ_PWNAM call at all times for this reason.

That brings me to my next question. Another requirement is that all
channels have to be temporarily disabled during reauth until the user
has successfully reauthenticated with the openSSH server. Is there any
mechanism to do that? I've tried many things, mainly in the
server_loop2() and channel_input_data() functions, but I can't get any
channels to stop accepting input/output and then start accepting it upon
successful reauthentication.

Thank you,
Eric

On 06/17, Damien Miller wrote:
> On Thu, 16 Jun 2011, Eric Anderle wrote:
> 
> > Hello all,
> > 
> > I have a question about the design of the privilege separation aspect of
> > openSSH. From what I understand, the interface between the privileged
> > process and the unprivileged one is implemented as a set of well-defined
> > operations with only a small subset of these operations enabled at any
> > given time. These operations are enabled and disabled depending on the
> > task at hand.
> > 
> > What I am wondering is why it was chosen to implement privilege
> > separation in this fashion, particularly the security implications of
> > this design.
> 
> The design and motivation of privsep is described in the paper:
> http://www.citi.umich.edu/u/provos/papers/privsep.pdf
> 
> Operations are generally only exposed when they are needed to limit the
> attack surface of the monitor, enforce correct protocol flow and reduce
> the opportunities for a compromised slave to reconnoiter through or
> request undesirable state changes of the monitor.
> 
> > Also, I would like to know if security would be weakened by allowing a
> > slightly larger subset of operations (namely, PWNAM) to be executed at
> > any time.
> 
> getpwnamallow() is used as a state-changing operation in the monitor,
> as it is called right before user authentication starts so you'd have to
> untangle that to begin with. 
> 
> Why would you want to call it more often? The user name isn't supposed
> to change during a session.
> 
> -d
> 
> 
>