[Karmic, security] Encrypted /tmp no longer mounting after upgrade to karmic
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cryptsetup (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: Mountall
(Swâmi Petaramesh 2009/12/21: De-duplicating this bug and affecting it to the mountall package per Steve Langasek suggestion in #475936 comment 12)
mountall doesn't wait for cryptsetup to finish setting up encrypted temporary filesystems (/tmp) and fails mounting them.
It sometimes affects encrypted swap as well.
The result is that the system boots with encrypted /tmp not mounted, and temporary files go unencrypted in the /tmp directory of the root filesystem.
Also, the system may have no swap after bootup.
----
- After upgrade from Intrepid to Karmic, encrypted /tmp and encrypted swap defined in /etc/crypttab do not work any longer, where they worked perfectly before.
/etc/crypttab entries are i.e.:
c_swap /dev/mapper/
c_tmp /dev/mapper/
/etc/fstab entries are i.e.:
/dev/mapper/c_tmp /tmp ext2 relatime,nosuid 0 0
/dev/mapper/c_swap none swap sw 0 0
Symptoms are :
- During boot, cryptsetup always properly creates and formats the encrypted c_tmp and c_swap volumes with random keys - so that's no cryptsetup issue.
The rest of the system behaviour is not always consequent :
1/ The encrypted swap is sometimes properly "swapon'ed", and sometimes not.
2/ The encrypted /tmp is NEVER auto-mounted although it has been properly created and formatted
3/ The startup scripts always spit a message stating that "not all the partitions defined in fstab could be mounted"
4/ The boot process *sometimes* hangs with a "Type root password or CTRL-D to continue", and sometimes not.
5/ When the system finishes booting, typing "mount -a" gets the encrypted /tmp properly mounted.
(It's worth noticing that I also have an encrypted /home using a permanent key, and this one still works flawlessly...?!?)
It appears to me that the startup scripts are doing things asynchronously or in the wrong order for encrypted filesystems, and that's a major issue.
The system running with /tmp not mounted, thus potentially sensitive /tmp data stored unencrypted in the root filesystem, I mark this as a security issue.
visibility: | private → public |
affects: | upstart (Ubuntu) → cryptsetup (Ubuntu) |
security vulnerability: | yes → no |
affects: | cryptsetup (Ubuntu) → mountall (Ubuntu) |
affects: | mountall (Ubuntu) → cryptsetup (Ubuntu) |
affects: | mountall (Ubuntu) → cryptsetup (Ubuntu) |
Hmmm... Scott assigned this bug to the cryptsetup package, but I still believe it's an upstart / initscripts issue.
Cryptsetup does its job good, but I believe there is an order or synchronization issue with the way the initscripts or Upstart call cryptsetup / fsck / mount of encrypted filesystems (i.e. try to mount them before activating the encrypted volumes).