5

Linux screen lockers don't seem so very secure, at least not in the past [1, 2, 3]. But is there any very secure OpenBSD screen locker?

(Or perhaps OpenBSD uses the same desktop related source code as Linux and therefore would have similar problems?)

Ideally, I'd like to be able to leave my laptop unattended, and know that after a few minutes, it'll screen lock itself, so it gets as safe as if the laptop had been powered off and full disk encrypted (all disks including swap). Is this possible with OpenBSD and screen lockers? Or would I have to configure the laptop to actually power itself off?

1: https://news.ycombinator.com/item?id=3484859
2: http://www.h-online.com/open/news/item/GNOME-screen-lock-ineffective-in-openSUSE-Linux-Update-928794.html
3: https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/
Related question, for Linux: What is the most secure way to lock a Linux Distros Desktop?

Community
  • 1
KajMagnus
  • 687
  • 1
  • 5
  • 10

2 Answers2

5

Altough OpenBSD made some enhancement to improve the security of X11 the problem is the underlying architecture of the X11 system which has no real (i.e. secure) concept of screen locking. This means screen locking is mainly realized by a process which grabs input and has a full screen window and if this process exits (normally or by crashing) the screen is unlocked. The article from Martin Grasslin you already mention describes the problems very clearly and these problem are no different on OpenBSD.

But, if the screen locking process tries to stay simple (like not trying to integrate with fancy desktop environments, show pretty animations...) or at least crash proof and if X11 itself has no real bugs apart from the design problem then screen locking usually works well enough. This is no different between Linux and OpenBSD.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Do you have any thoughts about what to do then, in order to get a safe "screen locker"? Perhaps let the "screen locker" be a script that saves the current X11 session to disk somehow, and then runs `poweroff now`? — I'm thinking that booting up again doesn't take long if one uses an SSD disk. And in my case, the OpenBSD session would consist of only a few browser tabs + ssh terminals, so saving the current X11 session (if that can be done, don't know much about X11) ought to be quick (it seems to me). – KajMagnus May 14 '16 at 10:31
  • 1
    @KajMagnus: no idea. Like I said - screen locking usually works well enough to deter the average user. And if you leave the system unattended for a longer time neither screen locking nor power off will really secure it anyway ([evil maid attack](https://www.google.de/search?q=evil+maid+attack)). – Steffen Ullrich May 14 '16 at 11:20
  • Ok. Thanks for the Evil Maid link, it was interesting to read. – KajMagnus May 14 '16 at 14:26
  • @KajMagnus there is no simple way of *"saving an X11 session"* other than system hibernation (most your X applications are not stateless, so saving the X session equals to saving state of *all* running X applications). Yet unless you are using a fully encrypted system (including the hibernation image - which you should anyway, if security is your concern), you'd end up with a running X11 session post hibernation. Hence the only thing between the attacker and your unattended (hibernated) X11 session would be pressing the power on button. – peterph Nov 03 '20 at 18:57
  • @peterph — then it seems to me the only safe "screenlocker" is full disk encryption and hibernating? It's just that with say 32 GB RAM, most of it in active use, it takes a while to hibernate and resume — and I wonder if maybe it's not good for the SSD disk to write that much RAM to the disk "really often" (?) – KajMagnus Nov 05 '20 at 20:22
  • @KajMagnus depends on your requirements and insistence on *safe* - practical security always boils down to striking the right performance/cost balance (like anything else, anyway). – peterph Nov 06 '20 at 22:22
  • @peterph if you have a closer look at the question, you'll notice that it actually defines what it means with *safe*: "powered off and full disk encrypted [...]" – KajMagnus Nov 12 '20 at 14:59
  • @KajMagnus you can't get "as safe as powered off" without powering off - the data would still be in memory. See [Neil Smithline's answer](https://security.stackexchange.com/a/123299/24330). – peterph Nov 28 '20 at 20:42
3

Ideally, I'd like to be able to leave my laptop unattended, and know that after a few minutes, it'll screen lock itself, so it gets as safe as if the laptop had been powered off and full disk encrypted (all disks including swap).

This is absolutely impossible. No matter how secure the screen lock is, as long as the computer is booted, it is potentially vulnerable to a cold boot attack. This cannot be fixed via any software. Even a computer not running an X server could be vulnerable to a cold boot attack.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
  • What about encrypted RAM? Then, if unplugging the RAM, it'd be useless? And the decryption keys could be stored in ... some dedicated thing, that, hmm, automatically shredded the decryption key, in case someone opened the laptop in the wrong way (e.g. opened it in order to remove the RAM) – KajMagnus May 14 '16 at 18:45
  • @KajMagnus the key to decrypt the RAM must be stored in a recoverable form in memory. So encrypted RAM makes it harder, but not impossible. – Neil Smithline May 14 '16 at 18:48
  • (I just edited my comment above and mentioned some (non-existing) hardware that attempts to deal with that, before I noticed you had replied already) – KajMagnus May 14 '16 at 18:50
  • @KajMagnus sounds like a TPM-like device that works on RAM. Still, never as secure as the key being nowhere but in your head – Neil Smithline May 14 '16 at 19:09
  • 1
    That is incorrect. You can encrypt RAM without having the key in memory, by storing it in another place like the processor cache or the debug registers. There are actually experimental hypervisors which can do this for you, such as TreVisor. Additionally, there are commercial solutions which encrypt all of memory, without the key being present in memory. And AMD is building consumer CPUs which are now able to encrypt all of memory transparently. – anon Sep 11 '17 at 07:47
  • As for the actual answer, it is easy to defeat a cold boot attack by using, for example, TRESOR, which stores the disk's encryption keys in the x86 debug registers, not memory. Likewise you can use your IOMMU to prevent DMA attacks. The only attack you cannot prevent (without physical modifications to your motherboard) is a JTAG attack, which utilizes a low-level debugging port on all Intel motherboards. – anon Sep 11 '17 at 07:48