[Libwebsockets] using unix or tcp sockets?
per at bothner.com
Tue Aug 29 08:43:56 CEST 2017
On 08/28/2017 07:38 PM, Andy Green wrote:
> On 08/29/2017 08:50 AM, Per Bothner wrote:
>> I'm looking into integrating session management (as in GNU screen or tmux)
>> into DomTerm (http://domterm.org). This seems to imply a separate "long-running"
>> server process that manages the various processes and ptys. Short-running clients
>> would send requests (such as "create a new session" or "list sessions") to the server.
> It sounds like it needs a really good security story.
My preliminary impression is that tmux (and Screen) handle security by not handling
remote or multi-user access themselves. For example If you want remote access you
ssh and run tmux on the remote server.
That may be a reasonable security story. It helps that ssh support port re-direction.
> Unless you know it can never split across the network, you at least want it to be able to use tcp sockets. That also lets you consider TLS certs / crypto as the security story throughout (ie, clients have to present a client cert before allowed to even set up the TLS tunnel).
Well, a "must-have" is that you should be able to just run
a 'domterm' command and the default behavior be to create a local
terminal emulator, without having to type any passwords or pre-user setup.
Just like running 'xterm'. It is highly desirable that this happen without
any root privileges or setuid code.
> A guy on github pointed out this
> however this is "simpler" in the sense of removing TLS support and all comments... I am still thinking about how to balance the "minimal code" part of the test apps and the "testing stuff" part of the test apps.
The goal isn't necessarily "minimal" but to have understandable examples following
> I would recommend testing the test client as is (you can point it at, eg, https://warmcat.com from the commandline which will do the GET) and then chop out everything not involved in your successful test.
It might be useful to use the "simpler" client.c to figure out what is needed
for a working client, even if I use the complex test client as a code base.
(I do want to have the client and server use the same 'domterm' executable.
That simplifies deployment. It also speeds up the initial server creation:
If a client doesn't find a running server, it can become the server,
and daemonize itself.)
> Since people will ultimately have authenticated sessions in their terminals they are likely to be paranoid about security, and it's difficult to make some value of "secure" after the fact. Especially if there's some central terminal server scheme potentially with authenticated sessions to all your boxes it would be the end of everything if someone malicious could get into it. So I would definitely think about a strong security story (eg, TLS client certs, or ssh keys) alongside the basic architecture at the first step.
Basing security on ssh seems appealing. It's nice it remote logins using DomTerm require no
more configuration that plain ssh remote login. I think that means program only have
the privilege of an ordinary user, and the websocket server only handles connection from
the user it is running as.
This does not handle the use case of a public login service (a la "shell in a Box"
https://github.com/shellinabox/shellinabox). That would require https/wss.
Time to sleep on this some more ...
per at bothner.com http://per.bothner.com/
More information about the Libwebsockets