Privilege Separation Design Question

[Cal Leeming [Simplicity Media Ltd]]

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