New Subsystem criteria for Match option block in OpenSSH server

[Nicola Muto]

Ok Darren, you confirmed my doubts about adding Match-Subsystem
option to sshd, most of all for the ChrootDirectory+PrivilegeSeparation
problem.

Now I have a question. What's that sounds bad, the implementation of 
the
patch or the Match-Subsystem idea itself?
In other words. Is it possible to solve all of these issues providing 
another
implementation? Am I doing something wrong or forgetting something?

If so, a new implementation should be not so simple and have heavy 
impacts
on the source. Moreover, I think that the Peter's issue can't be solved
by whatever implementation is proposed. Am I right?

If not then the Match-Subsystem solution itself sounds not a good idea.

Please, let me know what you think about. Thank you in advance.

> #2 has obvious security implications, but #1 can too.  For example: 
> do
> you allow the user to write to the chroot directory itself?

No user can write to the chroot directory.

\\nm



On 2012-05-23 05:54, Darren Tucker wrote:
> On Tue, May 22, 2012 at 06:01:17PM +0200, Nicola Muto wrote:
>> Darren Tucker write:
>> >I'm not convinced this is a good idea
>>
>> Why not? I'd like to understand what kind of problems you have with
>> the current implementation.
>
> I have two sets of problems with the patch.  The lesser of the two 
> were
> the implementation things I mentioned in my previous email.
>
> The larger and thornier set is whether or not this is a sensible 
> thing
> to do at all.
> 1) right now, the Match rules do not change the behaviour after the
>    username is supplied (very early in the logon process).  The 
> proposed
>    patch allows a whole bunch of things to change at run time in 
> possibly
>    unanticipated ways.
> 2) it doesn't (and can't work) with 
> ChrootDirectory+PrivilegeSeparation,
>    which negates a whole lot of the safety features in sshd.
>
> #2 has obvious security implications, but #1 can too.  For example: 
> do
> you allow the user to write to the chroot directory itself?
>
> You shouldn't (and there's a reason why there's a check for this), 
> but
> if you do, having ChrootDirectory on the list makes the exploit easy:
> in a single SSH session, open one shell session where you hardlink a
> setuid binary into the chroot, then use sftp to upload, say, a 
> backdoored
> libc into the chroot (and thereby activating ChrootDirectory), then a
> second shell session to execute the setuid binary which will load the
> backdoored libc from the chroot and do something nasty.
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3ou do  86E9 7EEE AF4B B2D4  37C9 C982 80C7 
> 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the 
> experience
> usually comes from bad judgement.