Bug 4591 - Restrict sshd TCP forwarding ports to Xvnc
Summary: Restrict sshd TCP forwarding ports to Xvnc
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Agent (show other bugs)
Version: 4.0.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.1.0
Assignee: Peter Åstrand
URL:
Keywords: hean01_tester
Depends on:
Blocks:
 
Reported: 2013-04-10 09:14 CEST by Peter Åstrand
Modified: 2013-06-03 11:35 CEST (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Description Peter Åstrand cendio 2013-04-10 09:14:51 CEST
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 Peter Åstrand cendio 2013-04-10 09:28:44 CEST
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 Peter Åstrand cendio 2013-05-16 12:47:41 CEST
Implemented in 27390.
Comment 6 Peter Åstrand cendio 2013-05-16 13:06:52 CEST
Shadowing issues documented in 27391. Closing.
Comment 8 Henrik Andersson cendio 2013-05-30 14:07:29 CEST
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 Peter Åstrand cendio 2013-05-30 15:03:08 CEST
(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 Henrik Andersson cendio 2013-05-30 16:58:18 CEST
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 Henrik Andersson cendio 2013-05-30 17:15:04 CEST
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 Peter Åstrand cendio 2013-05-30 17:20:15 CEST
(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 Henrik Andersson cendio 2013-06-03 08:05:40 CEST
(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 Henrik Andersson cendio 2013-06-03 08:45:23 CEST
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 Henrik Andersson cendio 2013-06-03 10:56:26 CEST
(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 Henrik Andersson cendio 2013-06-03 11:35:29 CEST
Verified functionality in a cluster setup using ThinLinc build 3970 and i could break the functionality, closing hereby this issue.

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