Security Issue - Linux Remote System Doesn't Properly Lock On Disconnect?
I'm a long-time Windows user who just moved over to Linux. Right out of the gate (unless I'm missing something), there seems to be a pretty big security issue:
*If I connect to a Linux host system from a remote Windows client, then disconnect, the remote Linux system doesn't lock. This is despite the Windows client being explicitly configured as: Extras->Options->Advanced->Lock remote computer=Always. In other words, the software leads you to believe that the remote will should be locked - but it's NOT actually locked. When you disconnect, the Linux machine is left sitting there just logged-in, such that anyone who happens to walk up can now begin using it. And you might not ever know. Likewise, if your remote connection drops, you might not even have a way to login & manually re-lock the host.
*Related, when connected to the Linux PC, Actions->Lock->Lock on session end is greyed. So it seems like there's no way to even proactively make your connection "safe" - aka to ensure it doesn't ever remain unlocked at the remote destination.
On Windows, hosts don't behave in such an insecure way; as soon as the client drops, whether they explicitly logout or the connection drops, the remote PC locks. This means you can connect from anywhere - i.e. even mobile clients - with confidence that the remote machine won't be left sitting unlocked.
Is there no way to have Linux hosts be the same?
Comments
-
...I reported this 3 weeks ago, still no reply. I tried reporting it directly to TeamViewer, but the Ticket link just redirects me back to this community support. I also tried submitting it to Sales, because it seems to be the only actual way they have to get in touch with them directly - but that was ignored.
Is there no way to report security issues to them which they won't simply ignore...?
0 -
Seven weeks, TeamViewer continues to simply ignore/disregard this issue report (both here and submitted directly). I'm beyond baffled. How on earth do they expect to address issues if there isn't even a proper way to report them?
0 -
9 weeks, till ignored.
0 -
14 weeks, they still can't be bothered to even respond.
0 -
TL;DR: No, there is not.
Linux isn't a homogenous platfrom like Windows. Linux is literally just the kernel that the operating system runs on. The option you are asking about does not exist on the TeamViewer Linux application because it is not practical. There are countless screen locking applications that could be employed, or ther may be none at all. The TeamViewer application has no way to know that. Your best course of action is to get in the habit of locking the Linux desktop session prior to ending the TeamViewer session.
As for the lack of reposnse to your question, while TeamViewer staff do sometimes respond to posts here, this is primarily a user community forum where other users just like you answer questions of their own accord. It is not a replacement for opening an actual support request if you have the expectation of receiving a response from TeamViewer.
HTH, and welcome to Linux
2 -
>Your best course of action is to get in the habit of locking the Linux desktop session prior to ending the TeamViewer session.
Sure, when possible - but as described, that's not practical or reliable in every case. i.e. maybe you were connecting from a mobile device & the cellular connection dropped, or maybe you're in a country that doesn't have stable internet (which is a very large portion of the world). If a disconnect ever happens that wasn't deliberate, you will end up with an unlocked remote computer - which you might not be able to reconnect with to lock. This isn't just a hypothetical - this exact situation has happened to me. It's a security risk that doesn't exist on the Windows version.
>The option you are asking about does not exist on the TeamViewer Linux application because it is not practical. There are countless screen locking applications that could be employed, or ther may be none at all.
I completely disagree. Yes, there may be one way of locking Windows and multiple flavors of Linux, but you could handle the vast overwhelming majority with just a few (KDE, Gnome, Xfce, Mate, Cinnamon). That's 5 conditional checks, 5 different lock commands. And even if they chose to implement it for, say, the top 25 environments - that's not exactly an "impractical" challenge.
...And at the very least, if it doesn't recognize how to lock the current particular DE, there should be a very clear warning when you connect: i.e. "If you don't explicitly lock the remote system before logging out, or if your connection drops, your user account will remain logged in & accessible to anyone at the remote location."
>It is not a replacement for opening an actual support request if you have the expectation of receiving a response from TeamViewer.
Their Ticket link just redirected me back to this community support. I also tried submitting it to Sales, because after searching high & low it was the only way I could find to get in touch with them directly (but as mentioned, that was ignored too). I posted here simply because they I tried to contact them directly, but couldn't make that happen either.
0 -
Hi @metal450,
Thank you for your post.?
In this case, we do not agree that this is a "Security issue".
We understand that this feature assists with security, however it's not being present on many Operating systems is not a vulnerability in and of itself.Please note that it is not currently feasible for us to develop this feature for Linux due to the variations in this space as we are sure you as a developer understand yourself.
Linux is a kernel, not an OS and the amount of OS's available are vast.
Linux as a whole does not have a native "Lock" feature that we can utilise. The function for this is not present in many builds and in others it varies wildly.We also do not have this feature when connecting to Android or Raspberry Pi for the same reasons.
I have put this in as a feature request for you, but this is not a feature that we currently offer.Thank you in advance for your understanding. ?
Kind regards,
YuriFormer Japanese Community Moderator1 -
>we do not agree that this is a "Security issue".
You say it isn't a security issue, but I really don't see how it could ever be safe to use TeamViewer to connect to a system unless it's either physically isolated (i.e. in my own locked office) or there's absolutely zero chance of the internet dropping at either end (which isn't the case in much of the world). Ultimately though, whether you call it a "security issue" or not is a matter of semantics - it might save face to not "call it" that, but it's an indisputable fact that it's designed in a way that could leave a computer vulnerable with no immediate way to rectify. As I have personally directly experienced.
Here's the actual, real-world scenario that happened:
I had my laptop in a coworking space (Regus) doing a very long build. I popped downstairs to the coffee shop while I waited. My laptop was physically locked to the desk (to prevent theft) and screen-locked behind a password. Periodically I'd use TeamViewer on my phone to check if it was done, to head back upstairs. At one point, the connection dropped. I didn't think it was an issue, as I had explicitly configured it to log me out on disconnect - so based on my trust that the software would do what was configured, I headed back up casually to discover that, despite the setting, it had actually been sitting there still logged-in & usable by anyone. Did someone sit down and look through my files while I was away? I have literally no way to know.
And now that I'm aware of the issue, I can't think of any way I could connect with Teamviewer like this & be sure that my computer won't be left vulnerable. Except, of course, using Windows, where it can be used securely - with effectively no risk of it being left logged in. Thus, it's really hard to perceive "we don't agree that it's a security issue" as anything but face-saving, considering it can and has created...a real-world security issue.
>Linux as a whole does not have a native "Lock" feature that we can utilise. The function for this is not present in many builds and in others it varies wildly.
Addressed above: "you could handle the vast overwhelming majority with just a few (KDE, Gnome, Xfce, Mate, Cinnamon). That's 5 conditional checks, 5 different lock commands. And even if [you] chose to implement it for, say, the top 25 environments - that's not exactly an "impractical" challenge."
>Please note that it is not currently feasible for us to develop this feature for Linux due to the variations in this space as we are sure you as a developer understand yourself.
As a developer, my view is the exact contrary - it seems pretty simple. As described, I understand that it might not be a single command like on Windows. But it would probably take one developer an afternoon to cover the vast majority. Pseudo-example:
if(is_freedesktop)
exec("qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock");
else if(otherDE)
exec("appropriate_lock_command");So maybe it'll take, what, 5 or 10 cases to cover the most prevalent desktop environments? An hour of googling to find the applicable commands for each, a few conditionals, & it's that's it? Am I missing some factor here that makes this not feasible?
>We also do not have this feature when connecting to Android or Raspberry Pi for the same reasons.
Which I would also view as a security issue, albeit one that doesn't affect me personally. "At the very least, if it doesn't recognize how to lock the current particular DE, there should be a very clear warning when you connect: i.e. "If you don't explicitly lock the remote system before logging out, or if your connection drops, your user account will remain logged in & accessible to anyone at the remote location."
0 -
> Please note that it is not currently feasible for us to develop this feature for Linux due to the variations in this space as we are sure you as a developer understand yourself
> Linux as a whole does not have a native "Lock" feature that we can utilise. The function for this is not present in many builds and in others it varies wildly.
From my experience the "Lock now" feature in TV on Linux already works. So the os-specific part that suffers so much from Linux being so heterogenous is already there and (at least in my experience) already works fine.
What is missing however is the code inside TV that glues the TV-lock-now functions to the TV-on-disconnect event.
0 -
@xplo wrote:From my experience the "Lock now" feature in TV on Linux already works. So the os-specific part that suffers so much from Linux being so heterogenous is already there and (at least in my experience) already works fine.
What is missing however is the code inside TV that glues the TV-lock-now functions to the TV-on-disconnect event.
Interesting. I apparently missed that feature's arrival. I was so used to it simply not being there on Linux, that I hadn't gone looking for it. That does considerably changes the feasibility of adding the autiomatic lock screen feature in the Linux TeamViewer package.
I just tested on an Ubuntu 16.04 LTS (Unity DE) and an openSUSE Leap 15.2 (KDE Plasma5 DE) endpoint, and it worked as expected.
If there is a tally of support for feature requests maintained somewhere, please add my endorsement to this request.
0 -
@Yuri_T It's been four months, & it's still not working properly. I feel that I addressed your points pretty thoroughly, & as others have since pointed out, the ability to lock in Linux is in fact already there. I'm not really sure why it's so difficult to engage in meaningful discussion with Teamviewer's staff/developers, nor am I really able to understand why such a seemingly simple fix for such a clear security issue would be ignored for what now amounts to eight months since originally reported. If I had access to the source code, I could probably fix this in a few minutes. Has this even been brought to the attention of the developers?
0 -
Seven months, still ignoring the points myself & other users have made.
0 -
Hi All,
Thanks for your posts.
I have put this in as feature request for you. Note that this is not a promise that it will be added, it is simply a request.
Please note: I am a community moderator. I cannot enact this change for you.
I have provided the best information available and forwarded your request.
Beyond this, no matter how many weeks or moths have passed, unless something changes, my answer will be the same.
We will not comment on this thread again unless something changes on our end.
Thank you for your understanding.
Kind regards,
Yuri
Former Japanese Community Moderator0 -
I have created a script for the "Lock on Disconnect," that utilizes the gnome-screensaver-command to lock after each session ends. I ran this script in Ubuntu 22.04. Basically, all you need to do is to execute this script in the background such as a screen. I have tried this with systemctl, but it causes crashing issues with the teamviewerd.system file, so I do not recommend this.
#!/bin/bash
TV_desktop='/opt/teamviewer/tv_bin/TeamViewer_Desktop' # Change to correct directory based on installation
pid_desktop=''
for i in {1..1000000}
do
while [ -z "$pid_desktop" ]
do
sleep 5 # Increase the sleep time if you want to reduce CPU consumption
pid_desktop=$(ps aux | grep -v grep | grep $TV_desktop | awk '{print $2}')
done
while [ ! -z "$pid_desktop" ]
do
sleep 5 # Increase the sleep time if you want to reduce CPU consumption
pid_desktop=$(ps aux | grep -v grep | grep $TV_desktop | awk '{print $2}')
done
gnome-screensaver-command -l # Do not use xdg-screensaver lock. This command may depend on your Linux Distro
done
Important Disclaimer: Do not use xdg-screensaver lock! This screenlock tends to generate network disconnection issues, which will cause TeamViewer to crash.
0
