gmane.network.openssh.devel

Re: New Subsystem criteria for Match option block in OpenSSH server

Ángel González — 2012-05-23T14:57:37

After reading Peter and Darren replies, I agree with them that a
Subsystem match to set forwarding makes no sense.

OTOH, I think you should be setting them globally.

Where you requested this setup:


What you need is probably this:

Chroot and executed command *are* a property of the subsystem. It's a
bit weird to have different chroots, but that's what you require.
No special reason to use ForceCommand instead of "Subsystem sftp
internal-sftp", though.

Re: New Subsystem criteria for Match option block in OpenSSH server

Ben Lindstrom — 2012-05-23T15:05:31

On May 23, 2012, at 8:31 AM, Nicola Muto wrote:


I'm not sure any patch would be acceptable.  The heart of the issue is simple:

Setup a ControlMaster,  start a shell connection to the server,  then start
a sftp connection reusing that control.  If you set anything like "don't allow
forward, etc"  now forward is disabled for the shell and for sftp.   This isn't
logical behavior that someone would expect unless they understood the
ssh protocol.

So unless you limit the protocol so you can only setup a single session type
(subsystem, shell, etc) per connection then I can't see how this is a sane 
feature for admins to wrap their heads around.

- Ben

Re: New Subsystem criteria for Match option block in OpenSSH server

Nicola Muto — 2012-05-23T13:31:45

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.


No user can write to the chroot directory.

\\nm



On 2012-05-23 05:54, Darren Tucker wrote:

Re: New Subsystem criteria for Match option block in OpenSSH server

Peter Stuge — 2012-05-23T09:12:09

Actually I think I understood.



My point is that this is extremely unintuitive and if the admin also
knows roughly how the SSH protocol works then it is directly
confusing. I am strongly opposed to introducing this kind of
indeterministic and inconsequent behavior into any program, and
into sshd in particular.


//Peter

Re: New Subsystem criteria for Match option block in OpenSSH server

Nicola Muto — 2012-05-23T08:11:18

Sorry guys, there was a misunderstanding due to my wrong words.

Instead, what I wanted to say is that a system administrator that is
configuring the ssh server with the following config lines, for 
example,

   ...
   AllowTcpForwarding yes
   ...
   Match Subsystem sftp
     AllowTcpForwarding no

"should know what he is doing". That is, the AllowTcpForwarding option 
put at
global level is active until a client sent an sftp subsystem request.
This is what comes out by reading the above configuration file; I 
think.

Sorry again, I'm disappointed.

\\nm


On 2012-05-23 00:14, Peter Stuge wrote:

Re: New Subsystem criteria for Match option block in OpenSSH server

Darren Tucker — 2012-05-23T05:54:21

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 c

Re: New Subsystem criteria for Match option block in OpenSSH server

Darren Tucker — 2012-05-23T04:05:57

[...]

It doesn't make sense.  subsystem requests, port forwarding requests
(and shell session requests for that matter) are all different request
types that may be sent in a single SSH connection.  There's no such
thing "connecting to the server using the sftp subsystem"; you connect
to the SSH server, then request zero or more of session, subsystem or
port forwarding requests an any order you please.

RE: New Subsystem criteria for Match option block in OpenSSH server

John Olsson M — 2012-05-23T03:37:16

I agree!



My interpretation (as an end user) of the construct shown below is that AllowTcpForwarding is not allowed for the SFTP subsystem, that is if you connect to the server using the SFTP subsystem. All other connection requests for other subsystems would still allow port forwarding.

Now I do not now how much sense the above makes.

Perhaps one should define a list of configuration statements that acts as a nop (no operation) when a match agaginst subsystem is done?


/John
________________________________________
From: openssh-unix-dev-bounces+john.m.olsson=ericsson.com< at >mindrot.org [openssh-unix-dev-bounces+john.m.olsson=ericsson.com< at >mindrot.org] On Behalf Of Peter Stuge [peter< at >stuge.se]
Sent: Wednesday, May 23, 2012 02:14
To: openssh-unix-dev< at >mindrot.org
Subject: Re: New Subsystem criteria for Match option block in OpenSSH server

Nicola Muto wrote:

The discussion has nothing to do with you or the needs of Ericsson.
OpenSSH behaving like the above would be absolutely retarded.


//Peter
__________

Re: New Subsystem criteria for Match option block in OpenSSH server

Peter Stuge — 2012-05-23T00:14:36

The discussion has nothing to do with you or the needs of Ericsson.
OpenSSH behaving like the above would be absolutely retarded.


//Peter

Re: New Subsystem criteria for Match option block in OpenSSH server

Nicola Muto — 2012-05-22T16:01:17

Yes.



Why not? I'd like to understand what kind of problems you have with
the current implementation.
The Match Subsystem will be triggered when the client is sending a
subsystem request and this should be the last config file reparsing.



These are very minor problems and could be solved using the ?: 
operator, as usual,
to avoid segmentation faults:

     str_ptr ? str_ptr : "(null)"

or, using the GCC compact format

     str_ptr ?: "(null)"

For that one could also write a CPP macro.
Personally, I wish that the C library implementations all behave the 
same way, at
least in these small cases.



Yes you are right. That issue was already in my mind.
Can it be solved defining a global instance of the ConnectionInfo 
structure
into the sshd.c file and importing it as extern into the other files so 
that
user, host, address, subsystem (and also lddress and lport) values can 
be
always available?



Sorry Darren, but that's exactly what I expect the ssh server should 
do,
reading this config. So I know wh

Re: New Subsystem criteria for Match option block in OpenSSH server

Darren Tucker — 2012-05-22T11:23:07

OK, so the way this works is that it reparses the config again when it
does the subsystem lookup.  I'm not convinced this is a good idea, and
there are a couple of problems with the existing implementation.

On Mon, May 21, 2012 at 04:15:16PM +0200, Nicola Muto wrote:
[...]
[...]

This will deref null pointers on most platforms.  glibc might save you,
but most libcs won't.


Because everything except the subsystem is nulled out a this point,
config lines like "Match User foo subsystem sftp" are syntactically
valid, but don't do what you'd think.

This reparsing could also change the server state in unexpected ways,
for example:

AllowTcpForwarding yes
Match Subsystem sftp
AllowTcpForwarding no

would allow port fowarding until you sent an sftp subsystem request.


In order to understand it, I forward-ported the patch to HEAD and
removed all of the unrelated changes.  (I haven't tested it, I'm only
including it in case saves someone the work).

RE: New Subsystem criteria for Match option block in OpenSSH server

John Olsson M — 2012-05-22T10:41:13

That was indeed a very dirty solution. :)

Good to know about, but I would very much like to avoid it if possible.


/John

Re: regarding Openssh

Peter Stuge — 2012-05-22T09:54:46

Actually *you* have to provide the analysis.

Please read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html


//Peter

regarding Openssh

Vc, Kavya (NSN - IN/Bangalore — 2012-05-22T08:49:30

Hello,

  Currently we have Openssh 5.1. But  I m not able to perform  ssh to
cluster ip.
Please provide the analysis.


Regards,
Kavya VC

Re: New Subsystem criteria for Match option block in OpenSSH server

Ángel González — 2012-05-21T17:06:43

Dirty workaround: the port 22 shell is is a setuid wrapper which exits
from the chroot, drops permissions and execs the "COM CLI".

Re: New Subsystem criteria for Match option block in OpenSSH server

Nicola Muto — 2012-05-21T14:15:16

So, is it better not to use the ConnectionInfo structure to handle the
subsystem request?
If you like it, I can rearrange the code and remove the subsystem field
from the structure in the file servconf.h.



All the sftp sessions should be chrooted and all shell session should 
not,
in any order they are opened.



I do not know well how the sshd server works internally and what
are its execution code flows, so I added a lot of traces to understand
better what's happening around the privilege separation concept.
These traces are in the file sshd-traces.txt attached to this email.
Well, with the privilege separation active the main process forks and 
drops
privileges definitively before I can receive the subsystem request. So, 
as you
can see at line 2.11 in the traces, when the client send the subsystem 
request
the process has a no-root UID and it's too late to perform a 'chroot' 
syscall.
Am I right?
I do not like, as you I think, to extend the time-window where the sshd 
process
is running with root priv

RE: New Subsystem criteria for Match option block in OpenSSH server

Nicola Muto — 2012-05-21T08:51:06

Hi

Much more details about what john's saying can be found at this
mailing list thread "http://marc.info/?t=132698105300002&r=1&w=2".

Anyway to better understand the problem I would like to report what
Hans wrote in an internal document about the wanted functionality.

It should be allowed to run, at the same time, a SSH server on
port 22 With two "conflicting" requirements:

1) It should allow the user to run a very high level "common line 
interface"
    (CLI shell) session simply by logging in with SSH
2) It should allow the user to run a SFTP session that is chrooted such 
that the
    user can only see the files managed by a "file management" software 
component
    and not the rest of the filesystem.

These two requirements are currently in conflict with each other, since 
the
OpenSSH implementation does not provide that feature out of the box.

Moreover, it was confirmed that the desired behavior cannot be achieved 
using
existing functionality. This is also confirmed by the OpenSSH user 
community.

RE: New Subsystem criteria for Match option block in OpenSSH server

John Olsson M — 2012-05-21T07:12:41

Hi,


I'm not sure what part you are referring to. What we need to be able to do is to place just the SFTP server in a chroot jail. But I'll give you some background so you can understand better what it is we want to do

We have a box/node/machine/server/whatever that runs SLES as Nicola wrote. This server has two SSH servers running; one on port 22 and one on port 4422. When logging in to port 22 credentials are first verified against /etc/passwd and then an LDAP server is checked if /etc/passwd failed, for port 4422 it is only /etc/passwd that is checked and SFTP subsystem is disabled.

If you just do a "normal" ssh login (without specifying any subsystem) you end up in what we call "COM CLI" which can be thought of as a text-based interface to an information model (you can navigate a tree structure, modify attributes and create objects, etc). This information model will also provide a branch showing a virtual filesystem. Thus this is a completely different animal compared to a Bash shell, it is purely a h

Re: Syslog via UDP for chrooted environments

Darren Tucker — 2012-05-19T04:20:32

One of the down sides of using UDP is that it's less trustworthy than
the local socket since it's easier to spoof.

Anyway, you could link in an alternative implementation of the syslog
functions at build time that do anything you want, you wouldn't need
to change the code.  Just implement openlog, syslog and closelog (or
the _r equivalents, if that's what your platform has) then ./configure
--with-libs=-lyoursyslog.

An alternative might be to use the existing code for sending log
messages to the monitor (which is not chrooted).  Much of the code
already exists (it was added in 5.9):

 - djm< at >cvs.openbsd.org 2011/06/17 21:44:31
   [log.c log.h monitor.c monitor.h monitor_wrap.c monitor_wrap.h sshd.c]
   make the pre-auth privsep slave log via a socketpair shared with the
   monitor rather than /var/empty/dev/log; ok dtucker< at > deraadt< at > markus< at >

Re: Syslog via UDP for chrooted environments

Peter Stuge — 2012-05-19T01:10:03

I'd suggest to submit it upstream, ie. OpenSSH in OpenBSD. I for one
think there is a point to have it, especially for the chrooted case.


//Peter

Syslog via UDP for chrooted environments

Matt Warner — 2012-05-19T00:24:23

Good afternoon.

I'm new to the list, so apologies in advance if the noob in me comes
through too loudly.

From things I've read in the distant past, I have the impression that
the OpenSSH project tries to keep new features to a minimum, and there
are good security reasons to do this. That said, one feature that I
feel would be a good addition to OpenSSH is the ability to send logs
via UDP directly to a syslog server. It seems to me that the benefits
of this approach include:

  1. No need to setup /dev/log in every chroot. This is a huge plus
for anyone dealing with a large number of chrooted users or in
environments where the underlying filesystem has the "nodevices" flag
set (I have both).
  2. The logs are sent directly from the application, with no reliance
on the syslogd of the host OS. For users that have separation of
responsibilities, having logs go directly to a syslog server
maintained by a separate group is a plus since it's more difficult to
tamper with the logs.
  3. The code to add the ability