Not sure if this classifies as a security issue or is known, but any user connected via SSH to Labs can use the "last" command and find the IPs of all the recent users on there.
|Resolved||bd808||T172650 "last" command on WMF Labs/Tools allows users to view IPs of other toolforge users|
|Resolved||bd808||T173845 Make potential for others to see IP Address for ssh sessions explicit in Toolforge membership request process|
|Resolved||bd808||T173846 Add warning about ssh ip address visibility to Cloud VPS TOU|
Some shared hosting environments do remove or alter tools like last, w, ps, and others that could leak sensitive or semi-sensitive information about other users and processes on the host. To my knowledge, Tool Labs/Toolforge has ever done this. I would be surprised to find out that Toolserver did it either. The information is not made available to the general public. This information is only disclosed to other Toolforge project members.
I think we can probably make this more obvious somewhere in the signup process and/or the on-wiki help.
Wouldn't the idea to remove those options also be up for discussion? There really is absolutely no need for "last" and probably the other commands to be used by "regular users". Toolforge/Labs access is not too hard to get, so anyone could "easily" get access to the sensitive/semi-sensitive information.
This probably needs some more serious discussion about the nature of tenants within Toolforge. Offhand we could set perms on utilities of this kind that do not allow everyone to run them, but roots/admins obviously have need. But their is a long tail of information available about Tool owners to other Tool owners within the ecosystem and I'm not sure our comfort level with that has ever been well defined.
The long tail is really my main concern. If we state that cross user information disclosure should not happen I'm afraid that we will either have to shutdown Toolforge or block significant portions of functionality that current project members use. Using a per-user chroot would certainly break many Toolforge workflows. Finding and removing/chmod'ing all of the things that users chould use to find information on other users and processes without chroot protections seems like a never ending game of whack-a-mole. The environment provides compilers and interpreted languages with easy access to system level apis, so merely chmoding standard system utilities will not be enough to block all cross-process information disclosure.
The original report is about IP address disclosure. I really think the answer to that concern is disclosing that this is a possibility and that individuals who are concerned that their IP address remain undisclosed should either not participate in the Toolforge project as maintainers or take other actions such as the use of TOR or an anonymizing proxy when connecting to Toolforge via ssh.
I wasn't sure if TOR/proxies were permitted while connecting to Toolforge, so if this option is preferred rather than limiting user options, as mentioned above it should be made more clear before registering.
A general notice about the nature of shared platforms that includes the ability for other users to gather connected IP addresses as well as determine status of users and such seems worthwhile.
This could be worth forking another task to discuss, but even if we found that this was greatly desired it would probably end up being low priority to implement. As @Luke081515 mentions this would be more likely to be workable for the normal Cloud VPS bastions than for the Toolforge bastions which really are not bastions in any traditional sense and instead are deployment and interactive shell hosts.
There are some (undocumented?) ideas about building a new interactive shell solution for Toolforge that could make isolation between users better not only for privacy but also for resource limit enforcement. That project is not on any concrete implementation timeline yet though.