Exposing Cookies To Dom0?

I’m making a script that will exit unless a keyfile is present. The problem is the script has to run in dom0. The keyfiles are on a USB.

As far as I can tell, I can’t expose dom0 to the USB safely?

Workarounds:

Cookies: Is there a way to write a session cookie, that will access the keyfile through a Qube, then write a cookie dom0 can access that expires when the system shutdown/logs out?

Sloppy workaround:
Copy the keyfile from the USB to dom0 through a Qube. Open the vaults on dom0. Delete the dom0 keyfile once vaults are open.

…something tells me the latter is not the way to go.

How would you solve this problem?

Make a service in sys-usb or in a dedicated Qube

1 Like

This questions belongs into User Support.

I’m drilling down in the docs on custom services. Not much more than this doc:

I’m still very unclear how to pass USB access to dom0 using a service.

Do you have an example of what that would look like in a bash script?

I mean you do not need to attach anything to dom0. You just need to provide dom0 access with necessary information – either via a custom service, or, if it is just a file, you can simply check it from dom0 side via qvm-run --pass-io

Okay, in this use case I’m trying to use the file as a keyfile in a Veracrypt vault.
Is there a way to pass access to the file without copying it to dom0?

Would there be a way to pass a text string directly to dom0 script thru a service, without copying to dom0?

Back when I was still working, I added a PAM authentication plug-in that checked for my Yubikey mounted in sys-usb. A script in sys-usb passed a nonce through an commandline encryption algorithm using the Yubikey’s key and if the proper value was properly removed the script returned the success value to PAM which allowed the login.

The cheviot is I had a fallback mode in case sys-usb was not running so that I would not be permanently locked out. This mode only worked if it could not start it and so assumed the system was borked.

You can just substitute your USB file for the Yubikey if you want. As long as your script returns the PAM success/failure id’s you can just roll your own solution.

You have the script handy?

I would not call it handy but I will look to see if I have a copy somewhere.

ssh

I could not find anything recent but I found a preliminary version when I started hacking on the dom0 side. Look at the PAM man pages to see how to hook it in. I don’t have any copy of anything custom on the sys-usb side either but this should at least give you some ideas. Obviously the values for KEY1 and KEY2 should be stored somewhere safe or encrypted in dom0.

The reference to “ykchalresp” sunning in sys-usb is here:
https://developers.yubico.com/yubikey-personalization/Manuals/ykchalresp.1.html

==================
#!/bin/sh

KEY1=“xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”
KEY2=“XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX”

challenge=head -c63 /dev/urandom | xxd -c 63 -ps
response=qvm-run -a --nogui -u root -p sys-usb "ykchalresp -2 -x $challenge"

function yubi_auth() {
correct_response=echo $challenge | xxd -r -ps | openssl dgst -sha1 -macopt hexkey:$1 -mac HMAC -r | cut -f1 -d ' '
test “x$correct_response” = “x$response”
return $?
}

yubi_auth $KEY1 || yubi_auth $KEY2

==================

fyi: One thing I did was to use the ‘beep’ utility while I was debugging so it would sing a different set of tones so I could listen to what the logic was doing. Depending on your threat model it might not be safe to leave ‘beep’ in dom0 once you have it working.