You are not logged in.

#1 2021-02-08 14:24:29

robertlturner
Member
Registered: 2020-05-20
Posts: 7

SoloKey Tap USBA - FIDO2 Build Support for 5.4.95-1-lts

Good evening,

I spent all of today learning pam.d and getting pam_google_authenticator.so & pam_u2f.so working together.  I'd welcome any feedback on my pam.d files and configuration below given the security impact of getting it wrong....

As per the subject though, it appears the LTS kernel doesn't build with libfido2 support?  The key works properly for the initial login, sudo, and su functions, but not for xsecurelock for systemd-homed.  There seems to be a fair amount of discussion around what configurations are supported between homed, display managers, screen locks, FIDO2, etc.  Can anyone comment on whether this is just a LTS kernel limitation, or definitively not something yet supported?

Details:

1. LVM on LUKS full disk encryption
2. Newly migrated systemd-homed user with --storage=luks.
3. New Solokeys running updated firmware 4.1.1.
4. Attempt to list FIDO2 tokens as per man homectl

 [rturner@SSDarchlinux ~]$ homectl --fido2-device=list
FIDO2 tokens not supported on this build. 

but visible using solo-python (AUR)

[rturner@SSDarchlinux ~]$ solo ls
:: Solos
20603793324B: SoloKeys Solo 4.1.1

5. Viewing build support using systemctl

[rturner@SSDarchlinux ~]$ systemctl --version
systemd 247 (247.3-1-arch)
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

6. libfido2 is installed

[rturner@SSDarchlinux ~]$ pacman -Q libfido2
libfido2 1.5.0-3

7.  I get the below error in journalctl when unlocking from xsecurelock (but no errors from fresh boot).

Feb 08 22:10:39 SSDarchlinux systemd-homed[601]: rturner: changing state active <E2><86><92> authenticating-for-acquire

Feb 08 22:10:39 SSDarchlinux systemd-homework[25806]: None of the supplied plaintext passwords unlock the user record's hashed passwords.
Feb 08 22:10:39 SSDarchlinux systemd-homed[601]: Authentication failed: Required key not available

Feb 08 22:10:39 SSDarchlinux systemd-homed[601]: rturner: changing state authenticating-for-acquire <E2><86><92> active
Feb 08 22:10:40 SSDarchlinux systemd-homed[601]: rturner: changing state active <E2><86><92> authenticating-for-acquire
Feb 08 22:10:40 SSDarchlinux systemd-homework[25807]: Provided password unlocks user record.
Feb 08 22:10:41 SSDarchlinux systemd-homework[25807]: Discovered used LUKS device /dev/mapper/home-rturner, and validated password.
Feb 08 22:10:41 SSDarchlinux systemd-homework[25807]: Successfully re-activated LUKS device.
Feb 08 22:10:41 SSDarchlinux systemd-homework[25807]: Provided password unlocks user record.
Feb 08 22:10:41 SSDarchlinux systemd-homework[25807]: Discovered used loopback device /dev/loop0.
Feb 08 22:10:41 SSDarchlinux systemd-homework[25807]: Read embedded .identity file.
Feb 08 22:10:41 SSDarchlinux systemd-homework[25807]: Provided password unlocks user record.
Feb 08 22:10:41 SSDarchlinux systemd-homework[25807]: Reconciling user identities completed (host and header version were identical).
Feb 08 22:10:41 SSDarchlinux systemd-homework[25807]: Reconciling embedded user identity completed (host and embedded version were identical).
Feb 08 22:10:41 SSDarchlinux systemd-homework[25807]: Everything completed.
Feb 08 22:10:41 SSDarchlinux systemd-homed[601]: rturner: changing state authenticating-for-acquire <E2><86><92> active
Feb 08 22:10:41 SSDarchlinux authproto_pam[25805]: pam_systemd_home(system-auth:auth): Home for user rturner successfully acquired.

And for anyone who finds this searching for these two modules and how to get a systemd-homed user login to work in combination with either/or the 2fa USB key or the Google 2fa OTP codes (with the newb security caveat above).  If you are playing with pam I highly recommend the advice to open a tty2 with root to recover your inevitable mistakes wink :

#%PAM-1.0

auth		required                    pam_faillock.so			preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
auth		[success=2 default=ignore]	pam_systemd_home.so
auth		[success=1 default=ignore]	pam_unix.so          		try_first_pass nullok
auth		[default=die]			pam_faillock.so      		authfail
auth		[success=1 default=ignore]	pam_u2f.so 			nouserok origin=pam://SSDarchlinux authfile=/root/.config/Solokey/u2f_keys appid=pam://SSDarchlinux cue
auth		required			pam_google_authenticator.so 	nullok user=root secret=/root/${USER}/.google_authenticator no_strict_owner
auth		optional			pam_permit.so
auth		required			pam_env.so
auth		required			pam_faillock.so      		authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

account		[success=1 default=ignore]  	pam_systemd_home.so 
account		required                    	pam_unix.so
account		optional                    	pam_permit.so
account		required                    	pam_time.so

password  	[success=1 default=ignore]  	pam_systemd_home.so 
password	required                    	pam_unix.so          		try_first_pass nullok shadow
password 	optional                    	pam_permit.so

session    	required                    	pam_limits.so
session    	required                    	pam_unix.so
session    	optional                    	pam_permit.so

With the secret files relocated to root and with permissions locked:

[rturner@SSDarchlinux ~]$ su root
Password: 
Please touch the device.
[root@SSDarchlinux rturner]# ls -alh /root/.config/Solokey/u2f_keys 
-rw------- 1 root root 823 Feb  8 11:58 /root/.config/Solokey/u2f_keys
[root@SSDarchlinux rturner]# ls -alh /root/rturner/.google_authenticator 
-r-------- 1 root root 176 Feb  8 14:42 /root/rturner/.google_authenticator
[root@SSDarchlinux rturner]# 

Thanks in advance!

Offline

#2 2021-02-08 19:42:21

loqs
Member
Registered: 2014-03-06
Posts: 13,177

Re: SoloKey Tap USBA - FIDO2 Build Support for 5.4.95-1-lts

Did you rebuild systemd to add libfido2 support?  https://bugs.archlinux.org/task/68823

Offline

#3 2021-02-08 22:57:38

robertlturner
Member
Registered: 2020-05-20
Posts: 7

Re: SoloKey Tap USBA - FIDO2 Build Support for 5.4.95-1-lts

Thank you for the quick reply.  I hadn't spotted that explicit change request for Arch.

I'm still very much a newbie so looks like systemd will be my first attempt at tweaking part of the kernel.  Not sure I'm a fan of doing so if a system update will then break my ability to unlock the home partition?

Any friendly links on how to get started?  I've just been watching a bunch of videos on how to get started with contributing to the kernel, so I guess this is as good of a learning opportunity as any.

Rob

Offline

#4 2021-02-08 23:31:12

loqs
Member
Registered: 2014-03-06
Posts: 13,177

Re: SoloKey Tap USBA - FIDO2 Build Support for 5.4.95-1-lts

Systemd is a separate project from the kernel.  Building a package is useful for working on any component in Arch.
See Arch_Build_System#Retrieve_PKGBUILD_source_using_Git or

git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/systemd"

To use the diff that adds support for libfido2 and tpm2-tss

cd packages/trunk
curl 'https://bugs.archlinux.org/task/68823?getfile=19655' > systemd.patch #obtain the patch
git apply -v systemd.patch

Then follow Makepkg#Usage or to make sure you do not pick up any unwanted additional dependencies follow Building_in_a_clean_chroot#Convenience_way
Then install the built packages.

# pacman -U systemd-247.3-1-x86_64.pkg.tar.zst systemd-libs-247.3-1-x86_64.pkg.tar.zst systemd-sysvcompat-247.3-1-x86_64.pkg.tar.zst systemd-resolvconf-247.3-1-x86_64.pkg.tar.zst #do not include any of the packages you do not have on your system

In case of emergency it is always useful to have live media so you can chroot in and restore the old packages.

pacman -S systemd systemd-libs systemd-resolvconf systemd-sysvcompat #do not include any of the packages you do not have on your system

Last edited by loqs (2021-02-08 23:31:41)

Offline

#5 2021-02-09 00:14:06

robertlturner
Member
Registered: 2020-05-20
Posts: 7

Re: SoloKey Tap USBA - FIDO2 Build Support for 5.4.95-1-lts

Thanks alot for the step by step! I had assumed since it was a core part of the system it'd be harder than just building an independent package from source.  Appreciate you pointing me straight to the needed patch!

Offline

#6 2021-02-09 15:26:15

robertlturner
Member
Registered: 2020-05-20
Posts: 7

Re: SoloKey Tap USBA - FIDO2 Build Support for 5.4.95-1-lts

Sooooo

1.  Building systemd only works if LANG=en_US.UTF8
2.  After successfully installing it, FIDO2 doesn't show up in systemctl --version

[rturner@SSDarchlinux ~]$ systemctl --version
systemd 247 (247.3-1-arch)
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

But the key is now detected both by homectl and the vendor solo-python script:

[rturner@SSDarchlinux trunk]$ homectl --fido2-device=list
PATH         MANUFACTURER PRODUCT   
/dev/hidraw0 SoloKeys     Solo 4.1.1

Unfortunately, trying to update the device to my user identity results in a buffer flow similar to that described in: https://github.com/systemd/systemd/issues/17784

[rturner@SSDarchlinux trunk]$ homectl update rturner --fido2-device=auto
Initializing FIDO2 credential on security token.
(Hint: This might require verification of user presence on security token.)
Please enter security token PIN: ******                  
Generating secret key on FIDO2 security token.
*** buffer overflow detected ***: terminated
Aborted (core dumped)

Generating a challenge response using solo-python as well as khefin seems to work, so the issue appears to be with the homed implementation?

[rturner@SSDarchlinux khefin]$ khefin generate -f test
Passphrase: 
Authenticator PIN for Solo 4.1.1 at /dev/hidraw0: 
157299f1f43858e7c3618e8369a403f8b09ce9bc414200fac6fc747cf842a2231721b361ca7f9abba19c2125a4696734ce64bf3c909c13ded62682206555a23f

Is my best course of action to open an issue on the systemd-homed github?

At this point it seems my questions will be more related to the PAM stack and homed implementations.  Should this thread be moved (or restarted) in the system administration area?

Rob

Offline

#7 2021-02-09 15:38:59

loqs
Member
Registered: 2014-03-06
Posts: 13,177

Re: SoloKey Tap USBA - FIDO2 Build Support for 5.4.95-1-lts

The system administration area is closed https://bbs.archlinux.org/viewtopic.php … 4#p1925104

You could try Pottering's fix.  See if that works for you.
Edit:
It depends on other changes only in master.  that why eight commits are being cherry-picked:

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 4d94265..e7956e1 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -14,7 +14,7 @@ makedepends=('acl' 'cryptsetup' 'docbook-xsl' 'gperf' 'lz4' 'xz' 'pam' 'libelf'
              'libmicrohttpd' 'libxcrypt' 'libxslt' 'util-linux' 'linux-api-headers'
              'python-lxml' 'quota-tools' 'shadow' 'gnu-efi-libs' 'git'
              'meson' 'libseccomp' 'pcre2' 'audit' 'kexec-tools' 'libxkbcommon'
-             'bash-completion' 'p11-kit' 'systemd')
+             'bash-completion' 'p11-kit' 'systemd' 'libfido2')
 options=('strip')
 validpgpkeys=('63CDA1E5D3FC22B998D20DD6327F26951A015CC4'  # Lennart Poettering <lennart@poettering.net>
               '5C251B5FC54EB2F80F407AAAC54CA336CFEB557E') # Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
@@ -59,7 +59,14 @@ sha512sums=('SKIP'
             'a50d202a9c2e91a4450b45c227b295e1840cc99a5e545715d69c8af789ea3dd95a03a30f050d52855cabdc9183d4688c1b534eaa755ebe93616f9d192a855ee3'
             '825b9dd0167c072ba62cabe0677e7cd20f2b4b850328022540f122689d8b25315005fa98ce867cf6e7460b2b26df16b88bb3b5c9ebf721746dce4e2271af7b97')
 
-_backports=(
+_backports=(e2f03674bc50263833ebc5b79a194cb667c0a244 #dlfcn-util: add DLSYM_ARG() helper
+            5517e214c8e6a18decf54884c9a5566fd7236764 #tree-wide: make use of new DLSYM_ARG() macro everywhere
+            69cb28965b9a835270a7def918e765ac156ae07a #homed: turn libfido2 into a dlopen() type dependency
+            fb2d839c0660482e6605a6766fb5e67e68f86a9d #homed: move fido2 device enumeration logic to shared code
+            17599e129b63b9dfdcbb1f6d223bbad70c4e7e92 #homed: move fido2 setup code to src/shared/
+            ebcb3f38d29418a10e408e983e5e81abcaeb178d #homed: split out HMAC-HASH fido2 decode code into src/shared/
+            e3fb662b6710134e3d52ea46ef2eb2c412c377c4 #fido2: don't use up/uv/rk when device doesn't support it
+            1abaa197814f21fa452eee2f9cf32cfc770908f4 #fido2: when listing fido2/hmac-secret devices, actually validate feature set
 )
 
 _reverts=(
@@ -110,6 +117,7 @@ build() {
     -Dlibidn2=true
     -Dlz4=true
     -Dman=true
+    -Dlibfido2=true
 
     # We disable DNSSEC by default, it still causes trouble:
     # https://github.com/systemd/systemd/issues/10579
@@ -154,7 +162,8 @@ package_systemd() {
               'quota-tools: kernel-level quota management'
               'systemd-sysvcompat: symlink package to provide sysvinit binaries'
               'polkit: allow administration as unprivileged user'
-              'curl: machinectl pull-tar and pull-raw')
+              'curl: machinectl pull-tar and pull-raw'
+              'libfido2: systemd-homed unlock using libfido2')
   backup=(etc/pam.d/systemd-user
           etc/systemd/coredump.conf
           etc/systemd/homed.conf

Use the following to remove the old patch before applying the above

git reset --hard

Last edited by loqs (2021-02-09 16:49:17)

Offline

#8 2021-02-10 01:01:08

robertlturner
Member
Registered: 2020-05-20
Posts: 7

Re: SoloKey Tap USBA - FIDO2 Build Support for 5.4.95-1-lts

loqs wrote:

The system administration area is closed https://bbs.archlinux.org/viewtopic.php … 4#p1925104

You could try Pottering's fix.  See if that works for you.
Edit:
It depends on other changes only in master.  that why eight commits are being cherry-picked:

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 4d94265..e7956e1 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -14,7 +14,7 @@ makedepends=('acl' 'cryptsetup' 'docbook-xsl' 'gperf' 'lz4' 'xz' 'pam' 'libelf'
              'libmicrohttpd' 'libxcrypt' 'libxslt' 'util-linux' 'linux-api-headers'
              'python-lxml' 'quota-tools' 'shadow' 'gnu-efi-libs' 'git'
              'meson' 'libseccomp' 'pcre2' 'audit' 'kexec-tools' 'libxkbcommon'
-             'bash-completion' 'p11-kit' 'systemd')
+             'bash-completion' 'p11-kit' 'systemd' 'libfido2')
 options=('strip')
 validpgpkeys=('63CDA1E5D3FC22B998D20DD6327F26951A015CC4'  # Lennart Poettering <lennart@poettering.net>
               '5C251B5FC54EB2F80F407AAAC54CA336CFEB557E') # Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
@@ -59,7 +59,14 @@ sha512sums=('SKIP'
             'a50d202a9c2e91a4450b45c227b295e1840cc99a5e545715d69c8af789ea3dd95a03a30f050d52855cabdc9183d4688c1b534eaa755ebe93616f9d192a855ee3'
             '825b9dd0167c072ba62cabe0677e7cd20f2b4b850328022540f122689d8b25315005fa98ce867cf6e7460b2b26df16b88bb3b5c9ebf721746dce4e2271af7b97')
 
-_backports=(
+_backports=(e2f03674bc50263833ebc5b79a194cb667c0a244 #dlfcn-util: add DLSYM_ARG() helper
+            5517e214c8e6a18decf54884c9a5566fd7236764 #tree-wide: make use of new DLSYM_ARG() macro everywhere
+            69cb28965b9a835270a7def918e765ac156ae07a #homed: turn libfido2 into a dlopen() type dependency
+            fb2d839c0660482e6605a6766fb5e67e68f86a9d #homed: move fido2 device enumeration logic to shared code
+            17599e129b63b9dfdcbb1f6d223bbad70c4e7e92 #homed: move fido2 setup code to src/shared/
+            ebcb3f38d29418a10e408e983e5e81abcaeb178d #homed: split out HMAC-HASH fido2 decode code into src/shared/
+            e3fb662b6710134e3d52ea46ef2eb2c412c377c4 #fido2: don't use up/uv/rk when device doesn't support it
+            1abaa197814f21fa452eee2f9cf32cfc770908f4 #fido2: when listing fido2/hmac-secret devices, actually validate feature set
 )
 
 _reverts=(
@@ -110,6 +117,7 @@ build() {
     -Dlibidn2=true
     -Dlz4=true
     -Dman=true
+    -Dlibfido2=true
 
     # We disable DNSSEC by default, it still causes trouble:
     # https://github.com/systemd/systemd/issues/10579
@@ -154,7 +162,8 @@ package_systemd() {
               'quota-tools: kernel-level quota management'
               'systemd-sysvcompat: symlink package to provide sysvinit binaries'
               'polkit: allow administration as unprivileged user'
-              'curl: machinectl pull-tar and pull-raw')
+              'curl: machinectl pull-tar and pull-raw'
+              'libfido2: systemd-homed unlock using libfido2')
   backup=(etc/pam.d/systemd-user
           etc/systemd/coredump.conf
           etc/systemd/homed.conf

Use the following to remove the old patch before applying the above

git reset --hard

That looks slightly more complex smile.  Are you saying I need to rebuild systemd from Pottering's branch of systemd referenced in the upstream bug report?  That the committed changes (limiting calls to functionality not supported by some keys) aren't in the master systemd branch used previously?

Apologies if its a simplistic question.  I've used git a little, but never 'properly' in this way before.  It's super powerful, will have to hit the books.  Thanks again and good morning to you!

Offline

#9 2021-02-10 16:32:12

loqs
Member
Registered: 2014-03-06
Posts: 13,177

Re: SoloKey Tap USBA - FIDO2 Build Support for 5.4.95-1-lts

The commits are in master,  they are not in 247 / 247.3 which is why they have to be cherry-picked.
Example using github https://github.com/systemd/systemd/comm … c412c377c4 shows no tags,  same check using git would be:

git tag --contains e3fb662b6710134e3d52ea46ef2eb2c412c377c4 

Offline

Board footer

Powered by FluxBB