Remote unlock SED via PBA

[Jip-Hop]

In addition tot the current unlock feature, I'd like to be able to unlock the SED over the network via the PBA in case I don't have a keyboard (and monitor) attached to my home server. This would also allow me to unlock the SED and boot the server if I'm not at home if I use a VPN.

For this reason I'm trying to re-enable networking in the PBA. I've set these to yes:

rear/usr/share/rear/prep/OPALPBA/Linux-i386/001_configure_workflow.sh

Lines 28 to 31 in 6a3d0b4

	# Disable non-essential stuff
	SSH_FILES='no'
	USE_DHCLIENT='no'
	USE_RESOLV_CONF='no'

And commented this line:

rear/usr/share/rear/build/OPALPBA/Linux-i386/095_exclude_non_essential_files.sh

Line 20 in 6a3d0b4

progs_to_exclude+=( arping curl dhclient dhclient-script efibootmgr ethtool ifconfig ip nameif netcat netstat nslookup route rsync scp sftp ssh strace tar traceroute vi )

When I boot from the PBA I drop to an emergency shell but I'm unable to ping anything. If I check ifconfig then there's only the lo network (no eth). What are the additional steps I should take to re-enable networking in the PBA?

If I can re-enable networking I'd try to remotely unlock using SSH. But ultimately I'd make a small HTTPS server with Python which would ask for the password and call sedutil-cli to unlock the disk.

[OliverO2]

For a (hopefully) complete list of files making PBA support possible, use:

find usr -iname \*opal\* -exec find '{}' -print \;

You might want to look at usr/share/rear/skel/default/etc/scripts/unlock-opal-disks which choreographs the final PBA boot stage and deals with final initialization, password entry and unlocking. It is called via usr/share/rear/skel/OPALPBA/etc/inittab or usr/share/rear/skel/default/usr/lib/systemd/system/sysinit-opalpba.service (depending on whether you are using init or systemd).

In the PBA, networking, sshd and stuff are intentionally left out to keep it small, simple and secure. Python is generally not available on a rescue system or PBA. Keep in mind the size limit for a PBA.

Note that all of this is well beyond scope for the current PBA implementation, so you're pretty much on open waters. Currently, remote unlocking requires firmware-level remote control capabilities (e.g. via IPMI oder AMT). Hope this helps anyway. Good luck!

[Jip-Hop]

Thanks for replying so quickly :)

My home server doesn't have IPMI and I'd prefer not to add it just for unlocking the PBA since it would constantly consume power.

I manually made a PBA image containing everything I need (including sedutil-cli, Python and networking) based on Tiny Core Linux. I still had room to spare, so I'm not worried about the PBA size limit.

I understand why networking is currently not available in the PBA image. Networking works in the rear rescue image though. I'm trying to discover why it works in the rescue image, and not in the PBA, so I can reenable it. Do you have another clue?

The rear workflow to generate a PBA image is super convenient! So I was hoping to build on top of it.

[OliverO2]

Unfortunately, I cannot point specifically to what you might be missing. As far as I remember, stripping down ReaR to meet PBA requirements was a complex multi-step process with a considerable amount of trial and error involved.

Your initial approach is on the right trajectory. However, rather than changing settings to different values, just comment out the lines you think might exclude stuff you need. For example, in 001_configure_workflow.sh do not set USE_DHCLIENT='yes', but make that line # USE_DHCLIENT='no'. The reason is that there are auto-detection and auto-configuration options in place which adapt to different installations and operating systems. See usr/share/rear/conf/default.conf for explanations.

So I'd go further down that route of initially commenting out everything that looks like a strip-down setting in 001_configure_workflow.sh, 095_exclude_non_essential_files.sh, including COPY_AS_IS_EXCLUDE lines (you might miss important configuration files otherwise). Also consider the hints mentioned in my previous comment. Then you could enable the debug shell via OPAL_PBA_DEBUG_PASSWORD (as explained in usr/share/rear/conf/default.conf), boot the image via a USB stick and check what's available.

Note that much depends on your base operating system and its configuration. ReaR images are generally way different from Tiny Core as the former can vary wildly depending on which OS they were created with.

[Jip-Hop]

Thanks again for replying. I went the Tiny Core Linux road after all for my PBA, but did borrow the rear SED unlock code from opal-functions.sh and unlock-opal-disks. I hope you don't mind 🙂

[OliverO2]

You're welcome! If it works best for you that way, it's perfectly fine. As ReaR code is GPL-licensed, who could object? 😃

[jsmeix]

@Jip-Hop
feel free to 'borrow' ReaR code as you like under GPL license
and ideally you may even bring something back to ReaR at a later time
if you have adaptions and enhancements that could also improve ReaR :-)