mikedotc
December 11, 2020, 6:51am
1
Hi All,
I was wondering if anyone had information on the following questions:
Is there a way to use LUKS2 instead of LUKS1 when encrypting a new drive to be added. I didn’t see any options in the Web Interface. It would be nice to utilize the newer hashing algorithms available in LUKS2. I also, did not see anything about this in the documentation or forums for either the Web Interface or via the Terminal.
Is it possible to add a previous LUKS encrypted drive that is using BTRFS?
Thank you.
-Mike
1 Like
phillxnet
December 15, 2020, 1:16pm
2
@mikedotc Welcome to the Rockstor community.
I had assumed we were using LUKS2 already actually. It’s been a while since I’ve looked at that code but I don’t think I did anything to limit out capabilities re versions. And from memory I think it may well have been a 2 variant that the LUKS capability was build on.
mikedotc:
Is it possible to add a previous LUKS encrypted drive that is using BTRFS?
This depends on the structure of the btrfs vol sub-vols within the LUKS encrypted devices. It’s definitely worth a try. You should be able to unlock the LUKS devices via the Web-UI, although again there are some limitations as Rockstor does have some limitations with regard to LUKS.
See the following pull request which may have some leads as to our current capabilities re LUKS:
rockstor:master ← phillxnet:1494_complete_disk_role_subsystem
opened 01:21PM - 23 Jan 17 UTC
As the role system enhancements within this pr are non trivial a developers tech… nical manual entry is planned in order to aid in further development / enhancement in this area. As such this pr messaging is constrained (in the interests of brevity) to bullet point abstractions of the changes as full explanations, and intended future use, can be reserved for the developers documentation to come.
A brief exposition of the merits of the approach taken is included.
Bullet points of changes made in this pr:
- extend the existing disk role system to accommodate general purpose use (previously used to flag mdraid members only)
- replace overloaded use of the partition property in the disks model for more specific disk categorization via the role system enhancements.
- add recognition of whole disk LUKS containers and their un-encrypted virtual devices to scan_disks()
- add recognition of bcache backing and caching device formats and their consequent virtual devices to scan_disks() (requires additional udev rules to be included in 'unofficial bcache package')
- add greater partition awareness to scan_disks() with a priority on reporting btrfs in partition.
- add filesystem within partition reporting to scan_disks() again with a priority on btrfs in partition.
- add contextual reporting of above on disk Web-UI page.
- add roles config Web-UI interface to report partition and filesystem status of a device and allow wiping of either specific partitions (once a redirect role is configured) and the whole disk. An introduction of future roles is included in the user facing text.
- add the 'User assigned' redirect role - essentially a flag that causes all disk actions to be redirected to a disk's partition.
- The disk wipe dialog was replaced by the above Roles config UI due to a required interdependence.
- all disk tables were updated to indicate redirect roles.
- disk and pool models and mechanisms were updated to be aware of both auto assigned (LUKS / bcache / root drive label) roles and User assigned roles (currently only redirect role).
The scope of this pr is larger than usual but was required for the following reasons:
- To develop and test the role system a number of auto and manual roles were required, hence the requirement to add recognition for root, LUKS, and bcache devices to prove role subsystem capability in more than one arena.
- To facilitate the testing of a user assigned role a web-ui interface was required in order to prove viability and the intended role mechanism with the interplay of auto and manual roles and added context that a redirect role, for example, brings: ie to the wipefs facility.
- The usability component of facilitating partition use via a redirect role attribution and how that tied into the existing UI also required a 'proof of concept' Web-UI.
The essence of this pr is to extend the disk management and recognition to accommodate more device types and partitions there in and to establish a mechanism by which those devices might be excluded or included contextually. The approach taken restricts Rockstor's use of partitions to one per disk. This is a majority use case in a NAS appliance. This approach also allows for the continued simplicity of a disk 'levels of analysis' approach which helps to keep the UI simple and approachable and avoids users having to be aware of partitions, except in specific use cases. One such case is the interoperability requirement faced when dealing with prior use (partitioned) external media for import or shared or intermittent use scenarios. However there is still a UI bias towards 'whole disk' for pool device members as this is a more elegant / ideal arrangement.
Testing methods employed are to follow in additional comment.
Fixes #1494
Ready for review.
and it’s associated LUKS specific follow up:
rockstor:master ← phillxnet:550_support_full_disk_LUKS
opened 06:23PM - 22 May 17 UTC
Abstract:
Adds full disk LUKS UI components to perform initial LUKS format and … set boot up configuration for the resulting container; with integral keyfile generation and registration where required. The consequent LUKS volumes also gain an ‘information only’ UI component to display their last recorded status which includes their backing container device. Further enhancements were required to the disk role improvements established in pr #1622 in order to meet the requirements of the UI components added. And to meet the expected pairing of LUKS data disk capability with encrypted system disk installs (via the “Encrypt my data” install option) the disk scan subsystem was improved to correctly propagate the otherwise incompatible LUKS in partition arrangement. Disk table view iconography was extended to indicate the open/closed status of LUKS containers.
Changes made:
- Add capability to appropriately indicate system disk use on encrypted installs.
- Improve iconic disk identification / tool tip info on disks page re LUKS.
- Add LUKS format tick to role/wipe page with relevant text and title changes.
- Add dual mode LUKS config/info page: Used for both containers and volumes.
- Report/configure /etc/crypttab config (boot up config) for LUKS containers/volumes.
- Partially account for existing udev sane LUKS config arrangements.
- Report last known status of LUKS volumes, including their container device.
- Enhance role and disk scan subsystems to accommodate the above.
- Add generic ‘mapped to pool’ icon to further clarify device state re btrfs.
- Add iconic indicator of pool member’s LUKS status on all main pool tables.
- Add in context explanatory text re LUKS passphrase, boot up config, and container / volume relationship.
Existing Pathologies:
- Removing a luks volume from an existing pool results in a detached device for up to 30mins after the end of a balance. Cause is as per commit: https://github.com/phillxnet/rockstor-core/commit/085e3871b4c51ccf16067f4ae19e5d9d7c0c67dc , however as a balance is often a long running process this artifact is less crucial and given the additional anticipated complexities of the same approach as per commit only applied directly after the end of a balance it was deemed worthy of it’s own issue / pr.
- When using a non keyfile boot up configuration the system has no way to authenticate reattachment of an auto detached LUKS volume (such as when a full volume fs is wiped). And so for the time being systemd-tty-ask-password-agent is a required at the console to enable reattachment prior to redeployment. Or a reboot as the name and user text presented against the relevant options suggests. To address this inelegance only the “Auto unlock via keyfile” option is recommended via user text. This could be addressed in the future when adding manual immediate container unlock UI components.
- Due to the extended use of the role field and it’s combined use to identify partitions and their filesystem, the existing 256 character db field limit can be exceeded upon encountering partitioned Open LUKS Volumes. However this is not a supported configuration. The existing issue #1709 will address this lack of robustness by way of quadrupling the disk.role maximum field length.
Configuration caveats:
- The only recognized way to identify which device is referenced in /etc/crypttab is via the containers uuid ie 2nd column must be of the form: UUID=3efb3830-fee1-4a9e-a5c6-ea456bfc269e however this is a commonly used and robust option.
- Keyfile location is non configurable via UI: all auto generated keyfiles will be placed in /root.
- No account is made for keyslot availability or configuration. However appropriate error messages should be surfaced.
- Only locked containers can be wiped and only if they also have no current boot up configuration (ie the “No auto unlock” selection). This is a safety measure and it is enforced by backend validation and front end function (ie the “Wipe locked LUKS container” link is otherwise hidden).
Noteworthy anticipated exclamations:
- It is assumed that existing LUKS configurations, identified as custom, will experience difficulties where the chosen mapped name for the resulting LUKS volume (first column in /etc/crypttab) does not begin with “luks-”. This is not recognized by udev in the same way and so does not receive a LUKS class of by-id naming: ie will not receive a “dm-name-” prefix in /dev/disk/by-id. In this case it is advised to proceed such names with “luks-” to attain on next reboot, a udev assigned dm-name-luks- by-id name. Or have Rockstor assert the luks-{uuid} type name by way of “Boot up configuration” reconfiguration.
Testing methods employed are to follow in additional comments to this pr.
Fixes #550
Please see #550 for development history.
Ready for review.
So from a quick review of those it looks like we do only support full disk LUKS so that may be a limiting factor in being able to import your existing LUKS drive.
Hope that helps.
1 Like