Circumvention of lockscreen key combination


#1

Hi there. When it comes to openbox and X I am pretty much a noob. I like what I see, I can change the menu and also managed to edit some of the polybar icons, however that is pretty much all I know. That is also one reason why I chose Archlabs.

So today I was at my cousin’s house and showed him my fancy new laptop with that cool operating system (archlabs). So I gave it to her, locked. However she managed to restart the (probably X) session by pressing [CTRL] [ALT] [ENTER] [BACKSPACE]. That way she entered the system without knowing my password.

First of all to my configuration: I guess she was able to get into the system because I do not use LightDM. However, I tested the shortcut also on my arch Desktop with KDE and on the Ubuntu Bionic Beaver of my cousin, however it would not restart X there.

I would guess installing LightDM would at least stop people from breaking into the system, but I am not so much of a fan of this, however. I chose not to install LightDM because I have encrypted my system and you already need to know that password to even start it up. I would also prefer not to do that in the next time. However, if it is necessary, I will do it.

I did check the Arch Wiki site about Openbox, but I did not find a shortcut to exit the X server. Searching the combination I found something similar to kill X ([CTRL] [ALT] [BACKSPACE]). Turns out, that works on my system. Now I know its not a bug, its a feature, but if it is a feature, I hope one can deactivate it?
Looking further I found something called dontzap, that is used to activate and deactivate this key combination. I found that in the arch wiki. That should prevent X from being killed. However, the file I need to edit does not exist. When I want to create it, I need to stop the X server first. Turns out, I can kill it, but I can not prevent it from respawning. :face_vomiting: So no creating that file for me. Tried to do it with chroot. For some reason I can not just decrypt the partition and mount it as stated in the arch wiki. I am quite fed up.

Does anyone have a good idea how to fix this whole issue? Also, why is this configuration the default on archlabs? I imagine that to be dangerous.


#2

Honestly, I’ve actually read this twice and my eyes are crossed… :astonished:

I would suggest a little less (coffee) and a tad more concentration… Please.

Flagging this for admin…


#3

Basically what @Booming is saying is that the lockscreen isn’t secure. ctrl+alt+delete kills X then automatically logs the user back in circumventing the whole idea of the lock screen.

@Booming, what I would do is to install Lightdm https://wiki.archlinux.org/index.php/LightDM.

It’s up to the user to secure their system. Not us.


#4

There’s a number of incomplete answers or answers that simply point you to install something else, these aren’t needed.

On Archlabs, in the directory /etc/X11/xorg.conf.d there is a file that provides this ‘low level’ Keybind to kill X 99-killX.conf

If you don’t want the ability to use the bind, simply delete the file.

This is the occurrence of a number of things setup on the system enabling this workaround to login while locked, mainly that your user is automatically logged in on tty1 when no other X is running, see /etc/systemd/system/getty@tty1.conf.d/autologin.conf and for starting X see ~/.zprofile for zsh (the default)

Also note installing lightdm doesn’t mean that this is resolved, depending on the setup the same workaround could be used there.


#5

I still have the kill X command and LightDM installed. ctrl+alt+delete drops me straight into LightDM. A password is still required to access the system.


#6

I wonder why you drive that policy? I thought that was why people use a installer? I mean, I can install Arch myself and all, that was important for me to have done before I install such a distribution, but when I need to find all possible attack points on my system I might just install Arch myself…

Though, for me it would have been nice to be told at some point of the installation, that I need to harden the system myself. A nice idea would be to include that hardening process in the documentation. I will see what else are possible weak points on my system, if I find some useful things, I would write that part myself. Though, because I am new here I would like to have someone look over it and approve it, because I am pretty new to the arch (and linux in general) world.

Edit: I think that arch wiki provides enough other information about the hardening process.


#7

Thanks for your reply and appreciate your feed back!!!
:smiley:

We don’t :slight_smile: An analogy for you, you purchase a car from a local dealership. Is it up to them to get the car serviced or the owner of the vehicle? Same applies here, we can’t be responsible for how you use your pc.

Generally I think a lot of people use an installer for the Arch spin offs for many reasons, I highly doubt hardening their system is one of the main draws.

Again, I do believe this is your responsibility to do or at least investigate.

My statement might not be in the correct context as far as this particular issue is concerned but I believe in what I said.

I fail to see how ArchLabs differs from Arch itself. Whether your system is installed via our installer or you install the traditional way, securing your PC is your responsibility.

To be honest the ctrl+alt+delete function to kill X has been a part of ArchLabs from the very beginning and this is the first time we have encountered this particular issue. Though saying that ArchLabs has defaulted to xinit rather than LightDM for logging in etc for the last few releases, though you have had the option of LightDM.

We have taken your issue on board and have removed the function from upcoming releases :smiley:


#8

That is nice to hear. :smiley:


#9

i actually like the kill X hotkeys but
fi didnt think it would kill the lockscreen… good i read this. I will jsut enable lightdm and everything is all set