In the interest of maximizing battery life, I’ve set up suspend-then-hibernate on my laptop. Using a discrete window manager, so I have a systemd unit that locks the screen when I close the lid. After an hour, it automatically goes into hibernation.
All is well, until I have to boot up from hibernation. I’m prompted to unlock LUKS, then I’m hit with a redundant lock screen once resumed. I’ve tried setting up systemd units referencing suspend-then-hibernate.target and hibernate.target, but I can’t get it to kill the screen locker when resuming from hibernation only, so I don’t have to type in my password twice. Is there any way to have systemd discriminate between the suspend and hibernate parts of suspend-then-hibernate?
You don’t want anything like what you’re attempting.
Instead, look into Clevis. Pair it with your TPM, and set it to handle the lower level LUKS challenge. Learn about it to understand the tradeoffs in security, but it’s going to be more secure than what you’re attempting.
This is for a SeaBIOS system without functional TPM.
Could you explain this? I do not see how it would compromise the security model since the lock screen would be dismissed only after the LUKS password is entered. The screenlocker is only relevant when suspended to RAM as the LUKS key is no longer in RAM once hibernated.
I am using
slock, which is separate from my session manager (startxin~/.profile), and in my testing, I was able to kill it without issue.If killing your lock screen unlocks the system, that signals there is actually little protection. Killing a lock screen should kill the session and log you out, or at least render the session unusable.
If you still want to go that route, you could wrap your hibernation process in a script or use a slightly more complex service setup to kill it once, by inspecting system/service state and enqueued systemctl operations, you determine hibernation is done (not pending)
How so? The lock screen is to prevent physical access while you’re away, and an attacker can’t kill it without having access in the first place. Any process that can kill it would already have access to your session.
Not all processes that can send a kill signal to another process have the same degree of access as physical access. The fact they are already running inside the session doesn’t automatically imply they have unrestricted access. In fact, you could argue no access at all a process has can compare to physical access. So that’s quite an escalation.
I don’t follow your thought process. I didn’t say every running process could kill the lock screen or if it can kill the lock screen it can access everything else, I said any process that kills the lock screen has to be running. And as the attacker with physical access doesn’t know the password they can’t run anything to kill the lock screen. The only way for them to unlock it is if they already have malware on the device, in which case their physical access isn’t the cause of the problem.
I’m focusing on the lock screen as having one single job to do well: protect the session from any access not granted exclusively through the password.
You posit this as if the attacker and the killing of the lock screen were connected: the attacker can only kill if they already have malware, so “it doesn’t matter”. But the point is, if the lock screen won’t relinquish access upon receiving the kill signal, even if the attacker had compromised this vector, or if there were some other cause behind the lock screen dying, crashing, whatever, access would not be granted in the first place. It stops at that layer.
Thinking in terms of “if they already can access the system, whatever” is different from thinking about security in depth/layers. So its not so much about the cause of the problem, but where you can contain it. This threat (a physical access attacker) is pretty extreme, but if we are going there, then yes, it’s not unfeasible to think that they could leverage this weakness to go from a possibly limited shell access to a fully unlocked physical session where you could have unrestricted access to e.g. a browser or unlocked password manager or other in-memory information.
But the two things don’t really need to be connected. The lock screen having a secondary way to allow access that does not require the password is a weakness in itself, that the attacker could exploit, but that should not have been there in the first place.
If you don’t care about the session manager password challenge, then set it to allow you to automatically login. Then you only have the LUKS challenge, and if you’re comfortable with that, go for it.