read only sessions

[ObiWahn]

Hi Nicolas,

i think it would be cool if a client could request to create a remote read only tmux server. I think it goes in the direction of the 3rd crossed out point in the future work section.

Maybe a "bool allow_read_only" could be added to tmate_session for the "server/demon role". Is that correct place for such information?

Regards

Jan

[nviennot]

Hi Jan Christoph, how is your suggestion different from the current readonly implementation?

[ObiWahn]

Ah is it already implemented? I was under the impression that always both types are created in the slave. So that you can connect to a read write session if you have or guess a valid key, is this not the case?
I would love to launch tmate with tmate--read-only and only the client that launched the session will have write access.

[nviennot]

I would love to launch tmate with tmate--read-only and only the client that launched the session will have write access.

I'm not sure what's the benefit compared to the current implementation where you can pick the r/w or read-only connection string.

[nviennot]

So that you can connect to a read write session if you have or guess a valid key, is this not the case?

Assuming an attacker can try a million tokens per second (which will hardly go unnoticed),
and assuming there's one billion sessions on the tmate.io servers, it would take him on average 10231884636185826482 centuries to guess a single session token.

So I wouldn't worry about someone guessing a valid key.

[ObiWahn]

Maybe the user gives out the wrong key because he has a bad day. An alias tmate="tmate --read-only" could save the day. I tend to do stuff like that on some systems really often. And be it so nobody powers down a server when he is about to shutdown his laptop to go home. The ability to modify such behavior is really useful.

[nviennot]

I see. I'll think about it in how to address the issue.

[AbdelElrafa]

Hi @nviennot Can you add this feature? It would be great to be able to launch readonly mode.

[eminence]

In the past I've given out read-only connection strings only to have someone discover the read-write string was visible in the terminal. Having a read-only mode that doesn't provide/show a read-write connection string would be useful to prevent these types of mistakes.

[nviennot]

Good point. Will add to the wish list.

[DustVoice]

For me one thing would even be sufficient: Having a --read-only flag, that just doesn't print the non read-only session keys!

I'm live streaming programming sessions and am using tmate, because one can't read sh*t at 480p. That means that I always have to launch a new tmate session on my 2nd monitor, as a viewer would be able to see the non read-only key for a brief amount of time. This is a big hassle for me and I would argue that just removing the output will be sufficient for me, because as you mentioned, brute-forcing the token would probably be harder than some kind of ip-based attack.

Thanks in advance for you SUPERB work. You have made my life so much easier. I really do appreciate it

[jonasstein]

default should be --read-only only if the user starts with --read-write it should be possible to get write access. A program should fall back to the safe condition if a parameter is missing or misunderstood.

[nviennot]

I agree, but I won't fix this anytime soon.

As a workaround, one can run:

$ tmate -F -S /tmp/tmate.sock | egrep 'locally|(read only)'
To connect to the session locally, run: tmate -S /tmp/tmate.sock attach
web session read only: https://tmate.io/t/ro-ML5bu8wsGZvsSwWqwxsH3eZcb
ssh session read only: ssh [email protected]

And then run tmate -S /tmp/tmate.sock attach to get onto the terminal. The read-write access token will not be shown on the display.

[omsai]

@nviennot I would love to have a configure --disable-session-write setting so that tmate only ever creates read only sessions for teaching purposes, and for my users to share their work without inadvertently sharing a writable link and therefore compromising their login accounts.

Would you be able to point me in the right direction so that I can work on a patch that does this? I see from your git history that you commits begin in June 1, 2013 where you add 4 source files, tmate.c, tmate-encoder.c, tmate-decoder.c, and tmate-ssh-client.c. Looking further through all of git log --patch I see:

1. The separation of references to session_name and session_name_ro in tmux.c
2. tmate-protocol.h TMATE_CTL_CLIENT_JOIN has a readonly attribute
3. cmd-choose-client.c has a client_readonly, (ro) string
4. key-bindings.c has an int readonly struct member

So my questions are:

1. What are the primary source files that a patch for --disable-session-write would cover?
2. Do you expect this can be implemented purely using preprocessor directives like #ifndef SESSION_READONLY ... #endif or that it should instead be implemented with the msgpack protocol?
3. Any other suggestions for where to look in the code and the scope of changes to make?

[nviennot]

I suggest hiding the write access session keys.

In tmate-decoder.c, change handle_notify to:

static void handle_notify(__unused struct tmate_session *session,
			  struct tmate_unpacker *uk)
{
	char *msg = unpack_string(uk);

	if (!strstr(msg, "session: "))
		tmate_status_message("%s", msg);

	free(msg);
}

The strstr call will check if the message to display corresponds to the write access session keys. If so, it will the write access session strings from the user.

[ObiWahn]

Is there a technical issue that keeps you from implementing read only sessions? Why do you insist on hiding just the string? What if people are not concerned about people guessing random numbers but you?

[nviennot]

There's no technical limitations. If someone sends a pull request for this feature that can be enabled by a --flag or an ENV variable, I'll take it

…

On Sat, Feb 20, 2021 at 9:04 AM Jan Christoph Uhde ***@***.***> wrote: Is there a technical issue that keeps you from implementing read only sessions? Why do you insist on hiding just the string? What if people are not concerned about people guessing random numbers but you? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACIQZEPHXJL6KHHSOOPI5DS766N3ANCNFSM4CDFTYEQ> .

[omsai]

Is there a technical issue that keeps you from implementing read only sessions?

@ObiWahn read-only sessions are implemented in pull request #207 which you can enable with --disable-session-write when running ./configure. For my use case, it's more worrisome to use a --flag or ENV variable which is why it made more sense to go the route of hard coding it at compile time. Does the configure method not work for you?

[jonasstein]

@omsai The default setting should always be the securest setting.

[nviennot]

Typically, ease-of-use and security are opposite forces. When implementing a feature, we must consider user experience while keeping the system reasonably secure against plausible threats. We must be cognisant of the user experience impact when adding security layers. In fact, one could argue that the most secure thing to do is to not use tmate at all, or avoiding turning on computers, but that would not be a satisfying experience for most. The default setting should be what most users want, in my opinion. From what I gathered over the years, the current default settings are adequate. I think the need for having a more explicit (and secure) interface can be achieved by having a more low-level layer that tmate can build upon. This way, different cliques of users having different needs can be satisfied equally.

…

On Sun, Feb 21, 2021, 12:05 Jonas Stein ***@***.***> wrote: @omsai <https://github.com/omsai> The default setting should always be the securest setting. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACIQZA7TCFLC4KHGPHVWLDTAE4MXANCNFSM4CDFTYEQ> .

[ObiWahn]

To be honest @nviennot is right on the trust issue:-) It reminds me of the ACM classic "reflections on trusting trust". If tmate-io would just collect all passwords it can get it was bad enough:)

Still for me just always sharing ro would be the best. And I would argue that rw is the setting most users want iff tmate would be used by hairdressers and plumbers. But you deal with technical people that rather use a terminal than zoom. And all individuals in this group I know of are pretty restrictive when it comes to their $HOMEs or accessing any other data on their machines.

Of course there are ways to mitigate the default rw behavior of tmate like: having an extra user that instantly denies sudo and su and does not have a lot of rights on the system.
Then you have to deal with the inconvenience that you need groups, extended file system attributes of both, that allow you to access the code you want to share. Or you sync the code via some SCM between users.

For now I have uninstalled tmate on all private machines and use wemux with trusted friends. Somehow I have the illusion that my PC is more secure. But it is probably just my head playing tricks:-)

And I think the sessions should timeout after an hour or so. Yesterday I found a 2 days old session:(