Proposal: User Autologin to X11 via LUKS Key

hede · 2013-11-21 14:09:15

I'm running several Linux Desktop Systems with Full Drive Encryption. cryptsetup LUKS. The main LVM group, incl. the root volume, gets opened from inside the initrd. I think many of you will know this.

And Linux is a multiuser Operating System, so there are several users all with their own LUKS Key. They first enter their key and then login to the System with different Usernames and Passwords. So why not login the user to the graphical UI via those different LUKS keys? They are already known when the system asks for username/password.

I do so. If I enter my LUKS passphrase at bootup, I get automatically logged in to my window manager. If my wife enters her LUKS passphrase, she gets logged in to hers.

rough draft: The key entered for cryptsetup inside the initrd (early boot) gets hashed and saved inside the memory. Later on in the boot process, the Desktop Manager startscript compares this hash to a list of hashes of different users and automatically logs in the one with the matching hash.

I attached the files I edited in my Debian 7 with gdm3, Arch Linux with vt-Login and Ubuntu 12.04 with lightdm.

For Arch it is f*cksystemd.c compiled and installed to /usr/local/bin/, this is used to get the hash from initrd to later userland, simply by adding it to the process stack and reading it later on via the "ps"-tool. That's crude, yes, but I didn't find a smarter way... (if you know one, tell me!)

Other files needed: hooks/encrypt and install/encrypt -> /usr/share/initramfs-tools/, loginuser.sh -> /usr/local/bin.
And my autologin@tty7.service seems a little bit outdated, someone has to translate it to the actual "automatic login to virtual console"

This is not a howto for end users, for now. No detailed install instructions. Just a proof of concept for discussion. If anyone is interested, please tell me. For me it works.

The name and many other things are subject for debate. I'm pretty sure there are smarter ways on the one hand for the hash transfer and on the other hand for autologon via Desktop Manager (I modify a symlinks to the DM-config every time (gdm3/lightdm)). Btw: The name f*cksystemd of the hash-transfer-binary accrued while trying to let systemd pass some environment variables from initrd to a boot script. Which doesn't work because systemd deletes the whole environment and this is not configurable. So I thought like Linus to NVidia: f*ck you, systemd! There should be some configuration option to whitelist environment parameters for single boot scripts and maybe delete them after running those scripts.

And because I cannot add Files to the Forums here, I uploaded the scripts there: http://limelinx.com/dejfq

Lone_Wolf · 2013-11-21 14:59:09

interesting concept, i do have an idea for a cleaner way to achieve this, but it is more complicated.
Also i have no idea if my idea can be implemented, so look at it as a THEORETICAL CONCEPT for now.

assumptions
x users, each with their own /home/$USER folder .
Every /home/$USER folder is encrypted and requires a unique LUKS key to gain access.
all those userkeys allow accessing / .

In the initramFS, the user enters their userkey.
LUKS unlocks /
a script then tries to unlock all /home/$user folders, using that same key.
the correct 1 is unlocked.
now normal init continues, and we switch to the normal environment.
Instead of a console / graphical login screen, a new script runs.

It verifies which /home/$user folder is unlocked, and autologins the corresponding user.

Some advantages :
the luks key is only used/necessary during initramfs
all /home/$user folders are restricted to access by the user they belong to.

teateawhy · 2013-11-21 17:55:09

Good idea.
If root is unencrypted, you can also use Pam_mount, which can unlock LUKS devices on login. ( I recommend not using pam_mount, because unmounting can be unreliable. )

vacant · 2013-11-21 21:01:08

Lone_Wolf wrote:

a script then tries to unlock all /home/$user folders, using that same key.
the correct 1 is unlocked.

Adding the username to the kernel boot parameter would mean a script could just read /proc/cmdline to find out which encrypted volume password to prompt for. i.e. duplicating the entries in (e.g.) syslinux.cfg for each user

LABEL tom
	LINUX ../vmlinuz-linux
	APPEND root=/dev/sda1 acpi_osi=Linux quiet rw ipv6.disable=1 tom
	INITRD ../initramfs-linux.img

LABEL dick
	LINUX ../vmlinuz-linux
	APPEND root=/dev/sda1 acpi_osi=Linux quiet rw ipv6.disable=1 dick
	INITRD ../initramfs-linux.img

teateawhy wrote:

I recommend not using pam_mount, because unmounting can be unreliable

Yes, I use pam-mount to unlock my encrypted home. It was very unreliable dismounting using gdm. I switched to lxdm and use the PostLogout script to make sure the volume umounts

frostschutz · 2013-11-21 22:55:09

Your method of grabbing the hash out of the process list is a bit weird, couldn't you just put it in /dev/shm instead or something?

Also from a security point of view, producing such a simple hash of the passphrase might be a security issue. Depends on who else got access to the box, who might be looking at the process list, or config files that list the hashes, etc. If someone gets the hash they could bruteforce much faster than normally possible, as LUKS builtin password hashing is much more expensive.

Personally I don't mind having to enter two passwords at all. Even if it's long enough to take a second or two to type.

Arch Linux

#1 2013-11-21 14:09:15

Proposal: User Autologin to X11 via LUKS Key

#2 2013-11-21 14:59:09

Re: Proposal: User Autologin to X11 via LUKS Key

#3 2013-11-21 17:55:09

Re: Proposal: User Autologin to X11 via LUKS Key

#4 2013-11-21 21:01:08

Re: Proposal: User Autologin to X11 via LUKS Key

#5 2013-11-21 22:55:09

Re: Proposal: User Autologin to X11 via LUKS Key

Board footer