www.cendio.com
Bug 4591 - Restrict sshd TCP forwarding ports to Xvnc
: Restrict sshd TCP forwarding ports to Xvnc
Status: CLOSED FIXED
: ThinLinc
VSM Agent
: 4.0.0
: PC Unknown
: P2 Normal
: 4.1.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2013-04-10 09:14 by
Modified: 2013-06-03 11:35 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2013-04-10 09:14:51
To be able to connect to Xvnc over the encrypted SSH channel, we create a SSH
TCP forwarding to Xvnc. This requires that the ssh daemon is configured with
AllowTcpForwarding. This also means that it is possible to request forwarding
to other ports and services, in addition to Xvnc. In some cases, this is
unwanted. 

One solution could be to dynamically add and remove local iptables firewall
rules. 

Another solution, which is likely better, is to use the OpenSSH daemon
configuration option "PermitOpen". In this case, we need to dynamically add and
remove such lines, then send a SIGHUP so the daemon, so that it reloads the
configuration. This needs to be done on the agent, as root. It could either be
done by vsmagent or tl-session. One advantage with the latter is that it can
more easily clean up when the session is finished. One advantage with doing it
in (the non-forked portion of) vsmagent, though, is that we would avoid
locking/concurrency problems. Also, tl-session is written in C, while vsmagent
is written in Python.
------- Comment #1 From cendio 2013-04-10 09:28:44 -------
There are also two possible approaches when updating sshd_config:

1) We could just add and remove the session that is started/ended. However,
vsmagent cannot easily detected an ended session. 

or

2) We could re-generate all PermitOpen lines, so that it reflects the current
status of the system. tl-limit-printer uses this approach. However, vsmagent is
stateless and thus does not have any information about current sessions on the
machine, but I guess it could enumerate the existing Xvnc processes running on
the system.
------- Comment #5 From cendio 2013-05-16 12:47:41 -------
Implemented in 27390.
------- Comment #6 From cendio 2013-05-16 13:06:52 -------
Shadowing issues documented in 27391. Closing.
------- Comment #8 From cendio 2013-05-30 14:07:29 -------
Tested using 3966 on SLED11 Sp2 and connection fails...

Client side:
2013-05-30T14:03:15: vncviewer[E]:  CConn:       connected to host 127.0.0.1
port 34000
2013-05-30T14:03:15: ssh[E]: channel 2: open failed: administratively
prohibited: open failed
2013-05-30T14:03:15: vncviewer[E]:  CConn:       End of stream
2013-05-30T14:03:15: Process 18427 exited with code 0
2013-05-30T14:03:15: Process 18432 exited with code 0


Server side:

2013-05-30 14:02:45 INFO vsmagent: VSM Agent version 4.0.0post build 3966
started
2013-05-30 14:02:45 INFO vsmagent: My public hostname is
dhcp-254-187.lkpg.cendio.se
2013-05-30 14:02:46 ERROR vsmagent: Unable to read sshd pid from
/var/run/sshd.pid
localhost:/etc/ssh # cat /var/run/ss
sshd.init.pid  sssd.pid
------- Comment #9 From cendio 2013-05-30 15:03:08 -------
(In reply to comment #8)
> Tested using 3966 on SLED11 Sp2 and connection fails...
> 
> Client side:
> 2013-05-30T14:03:15: vncviewer[E]:  CConn:       connected to host 127.0.0.1
> port 34000
> 2013-05-30T14:03:15: ssh[E]: channel 2: open failed: administratively
> prohibited: open failed
> 2013-05-30T14:03:15: vncviewer[E]:  CConn:       End of stream
> 2013-05-30T14:03:15: Process 18427 exited with code 0
> 2013-05-30T14:03:15: Process 18432 exited with code 0
> 
> 
> Server side:
> 
> 2013-05-30 14:02:45 INFO vsmagent: VSM Agent version 4.0.0post build 3966
> started
> 2013-05-30 14:02:45 INFO vsmagent: My public hostname is
> dhcp-254-187.lkpg.cendio.se
> 2013-05-30 14:02:46 ERROR vsmagent: Unable to read sshd pid from
> /var/run/sshd.pid
> localhost:/etc/ssh # cat /var/run/ss
> sshd.init.pid  sssd.pid

Re-fixed in 27467.
------- Comment #10 From cendio 2013-05-30 16:58:18 -------
Verified following tests on ubuntu 12.04 and it works as expected.

- ssh anyuser@host -L [5999/10000]:localhost:10000 and tried to telnet to local
port, got connection refused and following debug output was shown by ssh
"administratively prohibited: open failed".

- logged on using thinlinc and verified that an entry corresponding to user
  showed up in sshd_config, also verified that it was cleared at normal logout
and 
  by killing tl-session process.
------- Comment #11 From cendio 2013-05-30 17:15:04 -------
When testing with multiple session for same user, it fails because it seems
several PermitOpen rules should be whitespace seperated instead of several rows
as current implementation does.


It should be:

Match User cendio
  PermitOpen 127.0.0.1:5901 127.0.0.1:5901


instead of.

Match User cendio
  PermitOpen 127.0.0.1:5901
  PermitOpen 127.0.0.1:5902
------- Comment #12 From cendio 2013-05-30 17:20:15 -------
(In reply to comment #11)
> When testing with multiple session for same user, it fails because it seems
> several PermitOpen rules should be whitespace seperated instead of several rows
> as current implementation does.
> 
> 
> It should be:
> 
> Match User cendio
>   PermitOpen 127.0.0.1:5901 127.0.0.1:5901
> 
> 
> instead of.
> 
> Match User cendio
>   PermitOpen 127.0.0.1:5901
>   PermitOpen 127.0.0.1:5902

Fixed in 27471.
------- Comment #13 From cendio 2013-06-03 08:05:40 -------
(In reply to comment #12)
> (In reply to comment #11)
> > When testing with multiple session for same user, it fails because it seems
> > several PermitOpen rules should be whitespace seperated instead of several rows
> > as current implementation does.
> > 
> > 
> > It should be:
> > 
> > Match User cendio
> >   PermitOpen 127.0.0.1:5901 127.0.0.1:5901
> > 
> > 
> > instead of.
> > 
> > Match User cendio
> >   PermitOpen 127.0.0.1:5901
> >   PermitOpen 127.0.0.1:5902
> 
> Fixed in 27471.

Verified using build 3970 on ubuntu 12.04.
------- Comment #14 From cendio 2013-06-03 08:45:23 -------
Reviewed the documentation and it looks good but it raised the following
questions.

If using the port forwarding restriction it will break the shadowing
functionality due to shadow'er wont have access and must explicitly been added
to sshd_config to allow all port forwarding to sessione he wants to shadow.
Couldn't this been done using same semantics as for normal sessions, somthine
like; if new session is created, update all shadowers PermitOpen with the new
session port ?
------- Comment #15 From cendio 2013-06-03 10:56:26 -------
(In reply to comment #14)
> Reviewed the documentation and it looks good but it raised the following
> questions.
> 
> If using the port forwarding restriction it will break the shadowing
> functionality due to shadow'er wont have access and must explicitly been added
> to sshd_config to allow all port forwarding to sessione he wants to shadow.
> Couldn't this been done using same semantics as for normal sessions, somthine
> like; if new session is created, update all shadowers PermitOpen with the new
> session port ?

Apprently this is not doable due to shadowers are defined in vsmserver.hconf
and might not be availble on the agent where the specific sshd configuration
lives.
------- Comment #16 From cendio 2013-06-03 11:35:29 -------
Verified functionality in a cluster setup using ThinLinc build 3970 and i could
break the functionality, closing hereby this issue.