Privilege Separation Design Question

[Eric Anderle]

Currently, yes, we are forcing the reauthentication to happen via
password, regardless of how the user authenticated in the first place.
The plan is to start with password and then move toward making the
reauthentication more generic as to work with many authentication
methods.

On 06/30, Cal Leeming [Simplicity Media Ltd] wrote:
> May i ask, how are you going to handle shared key reauthentication?? What if
> the auth happened via a different pam module?? Simply checking passwd or
> shadow is going to be crude and not very effective. Unless i have missed
> something??
> On 30 Jun 2011 13:36, "Eric Anderle" <eanderle at umich.edu> wrote:
> > 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
> >>
> >>
> >>
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev