OK, I've had a bit of time to look through the available dracut docs and
have a couple of queries and a few ideas (below):
1. 'dracut -I' option 'installs' the files specified, but does it
install all dependencies? For e.g. if I want to install
'/usr/bin/pkcs11-tool' does it install all other libraries/files on
which this program depends (i do not mean just .ko files!)?
2. Currently the proposed rd_LUKS_KEYPATH and rd_LUKS_KEYDEV_UUID allow
me to specify key path and device to look for the key with which to open
the LUKS-encrypted drive/partition. If I want to open another LUKS disk
with a different key located in a different path/file how is this
handled? By specifying another pair of rd_LUKS_KEYDEV_UUID and
rd_LUKS_KEYPATH?
3. Following from 2 above: if smartcard module/enhancements are going to
be implemented then there is a possibility that there may be a conflict
(for example if I want to open drive A with keypath/file and drive B
with a token - how does dracut know which is which?).
So, I have an idea: instead of using rd_LUKS_UUID, rd_LUKS_KEYDEV_UUID &
rd_LUKS_KEYPATH (and possibly also rd_LUKS_TOKEN for reading keys from
tokens) why can't we have one unified and much simpler format:
a) for LUKS-encrypted drives (file/path keys):
rd.luks.<luks_uuid>=<keypath_uuid>:<fs>:<path>
For example
rd.luks.def0269e-424b-4752-acf3-1077bf96ad2c=3de247f3-5de4-4a44-afc5-1fe179750cf7:ext3:/crypto/key_file
opens LUKS drive with UUID=def0269e-424b-4752-acf3-1077bf96ad2c, using
key drive UUID 3de247f3-5de4-4a44-afc5-1fe179750cf7, mounting ext3 file
system and looking for file /crypto/key_file.
b) for LUKS-encrypted drives (using token keys):
rd.luks.<luks_uuid>=<reader_id>:<slot_id>:<token_id>:<token_status>
For example rd.luks.def0269e-424b-4752-acf3-1077bf96ad2c=0:0:12:private
opens LUKS drive with UUID=def0269e-424b-4752-acf3-1077bf96ad2c, reading
key token using reader=0, slot=0 and looking for token data stored with
application_id=12, where:
- reader_id: reader ID to use (not mandatory - if omitted the
'default' reader is used);
- slot_id: slot ID to look for when reading the token (it could
also be omitted in which case the first available slot will be used);
- token_id: the (application) ID of the token as stored in the
smartcard;
- token_status: 'public' if the token is stored in the smartcard as
'public' (i.e. no PIN login required - similar to the key path scenario
above); or 'private' if the key token is stored as a private token and
smartcard PIN is required to read the token data;
What do you think?
My main concern is handling of all dependencies when installing the core
programs, which are going to do the 'dirty work': pkcs15-tool and
pkcs11-tool (possibly pkcs15-init also, though this program may have to
be used in extremely rare circumstances, if at all).
I've looked through the dependencies and the package scripts though
there are, among other things, udev rules and config files, which could
complicate matters. Following this I have another query: Does dracut
have (at least read) access to the /boot partition where the initramfs
image is?
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
