[linuxpba] Allow password input from standard input and/or file. about sedutil HOT 9 CLOSED

@rookierks I am interested, and I guess many others could be. You could maybe make a git repo with your modifications for us to see how you did it?

from sedutil.

If you're writing a script you could just as easily use sedutil-cli to unlock the drive.

sedutil-cli --setLockingRange 0 RW <password> <drive>
sedutil-cli --setMBRDone on <password> <drive>

You could do whatever logic you required to check the success/failure of the command and then reboot or not as required.

from sedutil.

Didn't think of that, I'll give that a try once I have a bit of time.

One related thing, is it possible with opal 2.0 drives to have more than one administrator password? If yes, is it possible that all of them unlock the global range? The idea would be to do something similar to luks, where there are a few key slots (where password or keyfiles can be used) and each one of them unlocks the encrypted volume.

from sedutil.

I'm pretty, and sure that would work.
If I set up a script to unlock the solid state drive with the sedutil-cli command every time the machine starts, and lock the drive when the machine goes to sleep it would be so easy to get the data from the SSD if the machine was stolen.

1.Start up the PC.
2.Wait until it's fully started.
3.Disconnect the power source.
4.The contained data is ready to be retrieved. Useless SED.

In my case, I'm setting up an OPAL SSC implemented SSD on a server working in Linux.
Dangerous method.

I would make the unlock-lock script user specific, but it's almost the same thing.
The best way to unlock the drive it's providing a password to access without changing its settings.

So, maybe a most automated method is required.

The fact it requires to boot up again it's not a big problem, apart from the unnecessary time consumption (double system check).
A non-PBA method is required if the drive is not bootable.

Good work setting up this great utility.

from sedutil.

Wait a second, it's exactly the thing the utility does.

   if(d->MBREnabled()) {
        if(d->setMBRDone(1, password)) {
            LOG(E) << "Unlock failed - unable to set MBRDone";
            failed = 1;
        }
    }
    if  (d->setLockingRange(0, OPAL_LOCKINGSTATE::READWRITE, password)) {
        LOG(E) << "Unlock failed - unable to set LockingRange 0 RW";
        failed = 1;

Isn't that unsafe?
Is there another way?
Or am I missing the point where the SSD resets its locking range once a power cycle is done?

from sedutil.

@Foxofoxes What is unsafe? The drive is locked when the power is removed and you (or the person trying to use your machine) have to enter the passphrase to unlock the disk. If they enter an incorrect passphrase the machine reboots and they will get the PBA again. After the vendor defined number of attempts a power cycle is required to continue (AUTHORITY_LOCKED_OUT).

If the drive is not a boot drive then all they get is errors when they try to read the drive until it is unlocked.

If you write a script then the security is up to you. If you hardcode the password in the script then YOU made if unsafe.

from sedutil.

@r0m30
I have followed your idea and I've implemented my custom PBA image with support for keyfiles (key stored on usb drive/sd card), yubikey (challenge-response - the challenge is fixed, I know this is not the safest way but I wanted to avoid having to type a password) and as a fallback, password input. So I guess this bug/feature request can be closed.

I was wondering if there a forum or some way to make questions without opening a bug every time, I suppose it is better that things stay open but bug reports don't seem to be the best way to make questions or discuss something.

How I've done it (in case anyone is wondering):
The plaintext Admin1 password is stored inside a luks encrypted file that will reside in the PBA image. This luks encrypted file can be decrypted with up to 7 different keys, one of the keys is the yubikey's response to the challenge and at least another key is stored in a usb drive. This is done with a custom script that handles all the logic and uses sedutil-cli to unlock the SED.

from sedutil.

@snow3461
What I've done in regards to the PBA image is specific to Arch Linux as I'm using the already existing tools to create the initramfs, however the script that handles the logic (linuxpba-arch) should be generic. There is a package here [1], clone it and you have access to all the files. If you want I can also upload the files to a github repo later. Mind you that I didn't have time yet to write any documentation, I've finished testing and ironing out the bugs this past weekend.

[1] https://aur.archlinux.org/packages/sedutil

from sedutil.

@rookierks
Thank you, I had a quick look into it, and i'm affraid it's currently beyond my knowledge. Thanks for sharing though, I will try to look into it, and learn in the process.

from sedutil.