| 2009-12-21 07:19:12 |
Swâmi Petaramesh |
description |
Binary package hint: upstart
Hi,
I've seen this discussed (with no solution) in several forums posts, and I've seen some "about similar" bug reports, but not the exact same, or marked "incomplete", so I file this one as I believe this is a high priority and security issue.
- 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/VG1-c_swap /dev/urandom size=128,swap
c_tmp /dev/mapper/VG1-c_tmp /dev/urandom size=128,tmp
/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. |
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/VG1-c_swap /dev/urandom size=128,swap
c_tmp /dev/mapper/VG1-c_tmp /dev/urandom size=128,tmp
/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.
|
|
