Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 489974

Summary:	Encrypted /tmp partition prevents server from booting
Product:	Red Hat Enterprise Linux 5	Reporter:	Thomas <theitsmith>
Component:	initscripts	Assignee:	initscripts Maintenance Team <initscripts-maint-list>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE <qe-baseos-auto>
Severity:	high	Docs Contact:
Priority:	low
Version:	5.2	CC:	agk, dwysocha, mbroz, notting, prockai
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-02-11 21:47:02 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Thomas 2009-03-12 18:25:17 UTC

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.

Comment 1 Milan Broz 2009-03-12 18:58:30 UTC

/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.

Comment 2 Bill Nottingham 2009-03-12 21:03:30 UTC


*** This bug has been marked as a duplicate of bug 251494 ***

Comment 3 Bill Nottingham 2009-03-12 21:04:21 UTC

Whoops, wrong tab.

Comment 4 Bill Nottingham 2009-03-12 21:07:41 UTC

You're attempting to use /dev/urandom as a key, before the RNG is seeded. That won't work.

Comment 5 Thomas 2009-03-13 00:26:35 UTC

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.

Comment 6 Bill Nottingham 2009-03-13 19:10:38 UTC

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.

Comment 7 Bill Nottingham 2009-11-06 19:27:37 UTC

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.

Comment 8 Bill Nottingham 2010-02-11 21:47:02 UTC

Closing this as WONTFIX for now; this is too invasive for current RHEL.