f



Can I use my boot disk in rescue mode with an encrypted drive?

Hi All,

I am thinking that the coming release of CentOS 6.0 would be a mighty 
fine time to upgrade my office computer. Got my eye on an i7-930 and a 
Supermicro X8SAX.

Anyway, when I install CentOS 6 fresh on my new hard drives (RAID), I am 
thinking it would be a good time to take advantage of the whole hard 
drive encryption feature. That said, some questions:

1) this is a deal killer: does it allow me to boot off the install disk 
in rescue mode and unlock/see/read/write my encrypted hard drives? I
must have this feature as I am constantly screwing things up. (Not an 
admission I screw thing up. Maybe once or twice. Maybe.)

2) what is the performance hit?

3) do you guys think my idea of a whole disk encryption is "practical"?

4) okay, not an encryption question, but do we finally get to use ext4?

Many thanks,
-T
0
Todd
11/14/2010 5:28:55 AM
comp.os.linux.misc 33591 articles. 0 followers. amosa69 (78) is leader. Post Follow

6 Replies
672 Views

Similar Articles

[PageSpeed] 13

On Sun, 14 Nov 2010 00:28:55 -0500, Todd <Todd@invalid.com> wrote:

> 1) this is a deal killer: does it allow me to boot off the install disk
> in rescue mode and unlock/see/read/write my encrypted hard drives? I
> must have this feature as I am constantly screwing things up. (Not an
> admission I screw thing up. Maybe once or twice. Maybe.)

They would not be accessible, until the needed kernel modules have been
loaded, and the appropriate programs executed.  It can be done, but no
live cd/dvd I've seen, will do it by default.

> 2) what is the performance hit?

I use a luks encrypted file system for my data, and only notice a
performance hit, when copying a large file (such as a 4+GB file, to/from
the encrypted filesystem.  During normal usage, I see no difference.

The filesystem containing /boot must not be encrypted, or the boot
manager will not be able to read it.

> 3) do you guys think my idea of a whole disk encryption is "practical"?

No, as /boot must be readable by the boot manager.

> 4) okay, not an encryption question, but do we finally get to use ext4?

I've been using ext4 for all of my file systems, for about 6 months,
including those on luks encrypted containers.  The fsck speed of ext4
is much faster than ext3.  I've lost data stored on reiserfs and xfs
file systems (open files getting file length zero after a crash), but
have not lost any on ext4.

See http://www.ody.ca/~dwhodgins/Luks-Howto.html for an explanation of
how to set up a luks encrypted filesystem.

I'm currently using the Mandriva 2010.1 version of linux.  The bulk of
the system is not encrypted.  Even /home/dave, is not encrypted.  I have
an encrypted filesystem, that is mounted at login, that contains my email,
usenet, photos, documents, videos, etc, and have replaced the appropriate
directories in /home/dave with symlinks to those directories, in the
encrypted filesystem.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
0
David
11/14/2010 8:09:13 AM
On 11/14/2010 12:09 AM, David W. Hodgins wrote:
> On Sun, 14 Nov 2010 00:28:55 -0500, Todd <Todd@invalid.com> wrote:
>
>> 1) this is a deal killer: does it allow me to boot off the install disk
>> in rescue mode and unlock/see/read/write my encrypted hard drives? I
>> must have this feature as I am constantly screwing things up. (Not an
>> admission I screw thing up. Maybe once or twice. Maybe.)
>
> They would not be accessible, until the needed kernel modules have been
> loaded, and the appropriate programs executed. It can be done, but no
> live cd/dvd I've seen, will do it by default.
>
>> 2) what is the performance hit?
>
> I use a luks encrypted file system for my data, and only notice a
> performance hit, when copying a large file (such as a 4+GB file, to/from
> the encrypted filesystem. During normal usage, I see no difference.
>
> The filesystem containing /boot must not be encrypted, or the boot
> manager will not be able to read it.
>
>> 3) do you guys think my idea of a whole disk encryption is "practical"?
>
> No, as /boot must be readable by the boot manager.
>
>> 4) okay, not an encryption question, but do we finally get to use ext4?
>
> I've been using ext4 for all of my file systems, for about 6 months,
> including those on luks encrypted containers. The fsck speed of ext4
> is much faster than ext3. I've lost data stored on reiserfs and xfs
> file systems (open files getting file length zero after a crash), but
> have not lost any on ext4.
>
> See http://www.ody.ca/~dwhodgins/Luks-Howto.html for an explanation of
> how to set up a luks encrypted filesystem.
>
> I'm currently using the Mandriva 2010.1 version of linux. The bulk of
> the system is not encrypted. Even /home/dave, is not encrypted. I have
> an encrypted filesystem, that is mounted at login, that contains my email,
> usenet, photos, documents, videos, etc, and have replaced the appropriate
> directories in /home/dave with symlinks to those directories, in the
> encrypted filesystem.
>
> Regards, Dave Hodgins
>

Thank you!
0
Todd
11/14/2010 10:01:33 PM
On Sun, 14 Nov 2010 03:09:13 -0500, David W. Hodgins wrote:
<snip>
> 
>> 3) do you guys think my idea of a whole disk encryption is "practical"?
> 
> No, as /boot must be readable by the boot manager.
> 
Another alternative is to have "boot" (at least the kernel and initrd) on 
a bootable media (cd, usb-stick, etc.).
>
<snip>
>
I can't speak for CentOS, but there are a lot of possibilities in the DIY 
(do it yourself) school. I have hacked together a means of booting 
Slackware from usb, cd, etc. My simple startup environment gives the 
ability to perform various functions including the following:

	* setup,
	* generic startup including networking for any hardware,
	* "live" system using a device mapper target
	* encrypted startup using a device mapper target

Please note that startup environment is distribution dependent and mine 
has been setup for Slackware. From what I've learned almost anything is 
possible- that is, if the user is willing to invest some time in learning 
what to do. The final point seems to be the weak link in the chain. YMMV.

-- 
Douglas Mayne
0
Douglas
11/14/2010 11:19:35 PM
On 11/14/2010 03:19 PM, Douglas Mayne wrote:
> On Sun, 14 Nov 2010 03:09:13 -0500, David W. Hodgins wrote:
> <snip>
>>
>>> 3) do you guys think my idea of a whole disk encryption is "practical"?
>>
>> No, as /boot must be readable by the boot manager.
>>
> Another alternative is to have "boot" (at least the kernel and initrd) on
> a bootable media (cd, usb-stick, etc.).
>>
> <snip>
>>
> I can't speak for CentOS, but there are a lot of possibilities in the DIY
> (do it yourself) school. I have hacked together a means of booting
> Slackware from usb, cd, etc. My simple startup environment gives the
> ability to perform various functions including the following:
>
> 	* setup,
> 	* generic startup including networking for any hardware,
> 	* "live" system using a device mapper target
> 	* encrypted startup using a device mapper target
>
> Please note that startup environment is distribution dependent and mine
> has been setup for Slackware. From what I've learned almost anything is
> possible- that is, if the user is willing to invest some time in learning
> what to do. The final point seems to be the weak link in the chain. YMMV.
>

Over at Red Hat, I found this: http://www.redhat.com/rhel/server/details/

        Storage devices can be designated for encryption at
        installation time, protecting user and system data.

So, I was wondering if the installation disk, in rescue mode (note
this is not a live CD or a rescue CD, this is the "installation disk"),
had a way of looking at the hard drive.

-T
0
Todd
11/15/2010 3:39:14 AM
On Sun, 14 Nov 2010 19:39:14 -0800, Todd wrote:

> On 11/14/2010 03:19 PM, Douglas Mayne wrote:
>> On Sun, 14 Nov 2010 03:09:13 -0500, David W. Hodgins wrote: <snip>
>>>
>>>> 3) do you guys think my idea of a whole disk encryption is
>>>> "practical"?
>>>
>>> No, as /boot must be readable by the boot manager.
>>>
>> Another alternative is to have "boot" (at least the kernel and initrd)
>> on a bootable media (cd, usb-stick, etc.).
>>>
>> <snip>
>>>
>> I can't speak for CentOS, but there are a lot of possibilities in the
>> DIY (do it yourself) school. I have hacked together a means of booting
>> Slackware from usb, cd, etc. My simple startup environment gives the
>> ability to perform various functions including the following:
>>
>> 	* setup,
>> 	* generic startup including networking for any hardware, * "live"
>> 	system using a device mapper target * encrypted startup using a 
device
>> 	mapper target
>>
>> Please note that startup environment is distribution dependent and mine
>> has been setup for Slackware. From what I've learned almost anything is
>> possible- that is, if the user is willing to invest some time in
>> learning what to do. The final point seems to be the weak link in the
>> chain. YMMV.
>>
>>
> Over at Red Hat, I found this:
> http://www.redhat.com/rhel/server/details/
> 
>         Storage devices can be designated for encryption at installation
>         time, protecting user and system data.
>
Most probably the method of encryption thet have chosen is LUKS. LUKS is 
implemented as a layer on top of device mapper encryption targets. AIUI, 
you can unlock LUKS if you have the proper toolset (cryptsetup, device 
mapper, etc.) As a WAG, I wager that the proper toolset is provided as 
part of the setup and rescue environments. Verify for yourself. BTW, I 
have decided not to use LUKS and stick with simple device mapper objects 
and manage my own encryption keys. For me, LUKS was just "one too many" 
abstraction layers. YMMV.

> So, I was wondering if the installation disk, in rescue mode (note this
> is not a live CD or a rescue CD, this is the "installation disk"), had a
> way of looking at the hard drive.
>
I don't know because I don't use CentOS, RedHat, etc. 
> 
> -T

Note: comments inline.

-- 
Douglas Mayne
0
Douglas
11/15/2010 1:45:21 PM
On Sun, 14 Nov 2010 22:39:14 -0500, Todd <Todd@invalid.com> wrote:

> Over at Red Hat, I found this: http://www.redhat.com/rhel/server/details/
>         Storage devices can be designated for encryption at
>         installation time, protecting user and system data.
> So, I was wondering if the installation disk, in rescue mode (note
> this is not a live CD or a rescue CD, this is the "installation disk"),
> had a way of looking at the hard drive.

I doubt it.  While the installer's partitioning software may be able
to create encrypted filesystems, and create the appropriate entries
in /etc/crypttab an /etc/fstab (like Mandriva's diskdrake can do),
I doubt the rescue cd wlll find those files, and use them.  What
would happen if you boot from the rescue cd, on a system with more
than one linux installation on it?

I expect you would have to manually load the kernel modules, and then
run "cryptsetup luksOpen <rest>".

All rescue cds I've looked at use the output of blkid to generate
/etc/fstab entries, to use for mounting partitions, not the contents
of files on those filesystems.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
0
David
11/16/2010 8:19:53 AM
Reply: