I work at an IT company, started here not so long ago. Many of us are using linux, and I have discovered a problem or security issue with Ubuntu.
As it is now, locking the screen is of no use in case there would be a user-enabled process running a certain command: gnome-screensaver-command --lock
or loginctl unlock-session
None of the commands require a password to reactivate my desktop, and I honestly consider this to be pretty unsafe (or at least removing the safety around having a lock screen after all). I had expected it to ask for password when trying to re-enter the desktop environment.
I noticed this behavior upon developing my own bluetooth-lock functionality, so if someone moves away from the pc the screen will lock. But I had not expected it to be so easy to unlock it.
Are there any previous discussions around this? I find it very weird it is supposed to be this way.
In both use-cases, these seem like secondary issues.
If somebody can run
gnome-screensaver-command
orloginctl
as you, remotely, your home, your $PATH, essentially your whole computer —from the perspective of your security and privacy— is compromised.If somebody just rocks up at your computer, they can't just run this stuff.
No, this is not a flaw in lock-screen security
What do you expect to happen if you were to do something similar yourself for valid reasons? Say, you are using a different computer and you ssh into your usual one and run the command remotely?
This is something that we actually do where I work, as we have odd screensaver issues and haven't figured out why - our issue blocks someone from legitimately unlocking the computer, so they cannot get back into it. They generally walk to the nearest computer, ssh to the one that is locked, and unlock it remotely, then walk back. So what you described actually happens at my work location all the time.
It is not a security flaw because your computer should do what you tell it to do, and to the computer your user account is you.
So this could be a limit to security, a case that the security measures do not cover, but not a flaw in existing security. That would be like saying normal fences have a flaw in that they don't stop things from climbing or flying over them - no, that's not a flaw, just a limit to their security, one which you can implement other measures for if it's a concern.
Real-world analogy
As a physical analogy, you are describing crimes where thieves steal your house key when you're not looking, take it somewhere to have a copy made, then put the original back before you notice... and you are suggesting that this is a security flaw with keys that can be solved by banning key-copy services. Not that this would ban key-copying, as it would ban only the public service... people would still copy keys, just like people would still sneak malware onto your computer if you walk away with it unlocked.
How to increase security
The Bluetooth proximity unlock you mention sounds excessive, but if this is truly a massive security issue for your place, then that is one of the better ways to go. You probably don't even need to develop this yourself, as there are probably products which do this.
To continue the analogy, the Bluetooth proximity thing would be like having an alarm that triggered if your house key was moved too far from you. That would require thieves to do their work behind your back with you nearby; still possible, but more difficult.
Some other security methods might involve training people to always lock their screens when leaving their desks, or even further having a policy which states that all computers must be locked if the user is not within sight of it.
That is actually a policy where I work. If I walk away from my desk even just around the corner for 60 seconds for a coffee (which is in ear-shot of my desk and I can peek around the corner at it), and if I forget to lock my computer while doing so I can get into trouble. It is part of our security policy, and people are reprimanded for it.
Another thing to do would be reduce auto-lock timeouts. If they are at 10 minutes now, put them at 1 minute or less. That can be annoyingly short when reading a page of text, but if it's a big enough security concern then people need to just deal with it.
Reducing auto-lock time will stop your stated scenario from occurring in the cases where someone happens to walk by a few minutes after you walk away and see you're gone and your computer is unlocked. The vulnerability will be available only to those people who are actively stalking you and are ready and waiting to pounce on your user account seconds after you walk away.
Take-away
100% security is impossible
No matter what you do, it will not be possible 100% to stop what you describe. Someone can subvert a computer even if its user is present. Someone could stop by while you're at your desk, supposedly just to talk to you.
@Paŭlo Ebermann commented "Your attacker doesn't even type the command for the malware, his USB device can just pretend to be a keyboard too." Very true, thanks for making the point even better. Deleted extra unnecessary steps.
And that's assuming that you couldn't just get someone to run your malware themselves. "Hey Bob, can you try out my newest version of our software? I think I got the bug fixed." (Bob then runs the software he is developing with Tim, not knowing Tim put malware in that specific build of it, then Tim deletes it in 5 minutes)
That's all it takes, then your computer account is already 100% compromised, even while locked.
It is practically impossible to protect a user account from the actions taken by that user account, and
it is practically impossible to guarantee that the actions taken by that account are all exactly what the account's human owner desires.
To go back to the analogy...
I used the key example because of your specific lock-screen case, wherein the lock-screen is the key. But, as pointed out by commenter @David Z, the problem is actually worse. By analogy, the key theft is a minor concern as you already have people living in your house without you knowing it, and they are doing whatever they want all day while you are gone, even though your door is locked.
If you're fortunate they will leave a mess and you'll come back to a home that looks obviously ransacked. "What??? If I'm fortunate?" Yes, because the worst case is far worse. They could live in your house for years, always picking up after themselves, so that they can keep stealing from you and living in your home for years without you even noticing. Or even using your home as a hub for criminal activity, like drug sales or pawning stolen items.
That would be like your office's computers all having key-loggers, remote control software, constantly downloading all your company data, or even being consumed as part of a botnet such that those computers could actually be engaging in illegal activity every day without you even knowing. All while the door is still locked.
I just stumbled on this great XKCD joke and it reminded me of this answer, so I've added it. Notice the 5th "security vulnerability" from the bottom.
I am reminded of this U&L question about sudo granting root access. Yes, a command running under your user account is able to unlock your computer. This is because, under Linux's security model, any command running under your user account is you.
There is effectively no difference between a command issued by a program that you launched and a command that you issue, whether through the GUI or a terminal. If you are running program that unlocks your screen automatically, your screen is unlocked, because there is no distinction between you clicking a button triggering the program and the program running some other way. If you run a program written by a malicious attacker, then your user account is totally and irrevocably compromised. A service written by this attacker could unlock your computer, yes, but the service could also allow remote access to your session already, or do anything the attacker wants.
So yes, you could possibly configure your system to only allow a program that does prompt for your password to unlock your system. But if you have to do that, if you're trying to prevent a malicious program, running under your user account, from compromising your user account, then you have already lost.
TL;DR: The program can do that because it's already logged in as you. You can do that because it's your account, just like how you can
rm -rf ~
. UNIX-like systems have traditionally not been in the business of preventing you from shooting yourself in the foot. If you can't keep control of what runs under your account, you've lost control of your account already.Other answers focus on attackers, where it absolutely isn't a security flaw, because you need to already have access to run this command.
However, there is another concern here. In a company, IT security needs to be able to secure computers without the user being able to change security settings. In the scenario of an employee who is annoyed by locked screens, the employee can schedule a chron job to unlock the screen on a regular basis, effectively keeping the computer unlocked entirely. This weakens the security of a device/account significantly. So yes, it is a problem. Such a system is not adequate in terms of company IT security.
This is not a security risk.
If an attacker is logged in as you (or root), and is able to run this command, then they don't need to - they are logged in as you, so they can already run any program as you.
Disclaimer: I don't work in IT, but I do play BOFH when given a chance.
It seems here that the proper solution in a workplace environment is for IT to push out controls/tools/whatever which force all users' machines to run password-locked screenlocks. Disable the specific commands which turn that off. Just keep in mind the unbreakable law "Whenever you make a system foolproof, Nature invents a bigger fool."