Description of problem: When I configure crypttab and fstab as follows, the server is ALWAYS unable to detect the configured tmp file system. The result is that the server prompts for the root password during boot and is unable to continue beyond that point. /etc/crypttab: luks_swap /dev/vg_main/lv_swap /dev/urandom swap,cipher=aes-cbc-essiv:sha256 luks_tmp /dev/vg_main/lv_tmp /dev/urandom tmp,cipher=aes-cbc-essiv:sha256 /etc/fstab: /dev/mapper/luks_swap swap swap defaults 0 0 /dev/mapper/luks_tmp /tmp ext2 defaults 1 2 (non-relevant entries removed for clarity) The swap file is detected and enabled correctly but luks_tmp is not and will prevent the server from booting. Version-Release number of selected component (if applicable): RHEL 5.2 (from DVD) How reproducible: Always. Steps to Reproduce: 1. Create the crypttab and fstab (and associated LVs) as illustrated above. 2. Reboot. Actual results: The server prompts for the root password during boot, stating that it was unable to locate /dev/mapper/luks_tmp. Expected results: That the server starts encryption BEFORE its file system checks, much in the same way that LVM is started prior to the file system checks. This would allow those file system checks to access the LUKS-encrypted partitions. Additional info: I noticed that during boot up, the server does its file system checks BEFORE enabling the encrypted partitions. Yet the swap partitions are enabled AFTER the encrypted partitions and thus those work fine while luks_tmp does not. If I remove luks_tmp from fstab, the server boots fine. Then I'm able to manually mount luks_tmp to /tmp without any problems. Doing it this way, though, has reprocutions as several services that startup during boot make use of /tmp--so mounting /tmp after the server has booted (via rc.local, for example) would also require a restart of the relevant services. I think that this is a critical issue. Securing /tmp, as well as swap, plays an important role in overall server security. I have not tested any workarounds to this problem--some advise in this regard would be greatly appreciated. PS: I wasn't able to locate a more appropriate Component, so I selected cryptsetup. Please advise if there is a more appropriate one for this issue. Thank you.
/etc/crypttab is processed by inittscripts, reassigning to that component. (the tmp option is documented in crypttab man page, so it really should work...) Just note - using random key means that partition doesn't use LUKS but simple crypt mapping.
*** This bug has been marked as a duplicate of bug 251494 ***
Whoops, wrong tab.
You're attempting to use /dev/urandom as a key, before the RNG is seeded. That won't work.
Yes, but the fact still remains--this is a documented capability in the crypttab man page. So one would expect it to work as advertised. In order for my desired partition layout to work, things need to be started in this order: 1) LVM. 2) RNG. 3) Encrypted partitions. 4) File system checks, etc. 5) swap partitions. For those who use software RAID, that would need to be handled prior to LVM. But the order things are loading in appears to be this: 1) LVM. 2) File system checks, etc. (This is where luks_tmp is failing, for reasons stated in the previous post.) 3) RNG. 4) Encrypted partitions. 5) swap partitions. Would it be possible to modify the order that these things are initialized in? The ability to do have an encypted /tmp partition, just like swap, adds to the overall security of the server. And since /tmp really has no reusable data between boots, it also makes sense to be able to use a random key.
RNG requires a readable /var, to get the seed to put in the RNG. This may not be available until after fsck, as it may not be mounted then if it's a separate fs. It also requires writable /var, to save the seed once it's initialized. Obviously, that doesn't work until after fsck & remount r/w.
Oof, getting back to this. The only fix likely to be pushed for RHEL, due to the invasiveness, is to remove /dev/urandom as a documented use case.
Closing this as WONTFIX for now; this is too invasive for current RHEL.