3:50 a.m.
Hi all!
I want to know how I can encrypt my /home partition which is inside a
Logical Volume to increase the security. Also, should I also encrypt the
main / partition??
All help and guidance are well appreciated.
Thanks,
Amit.
5:42 a.m.
On Mon, Dec 24, 2007 at 06:24:43AM -0500, Robert P. J. Day wrote:
On Mon, 24 Dec 2007, Luciano Rocha wrote:
> On Mon, Dec 24, 2007 at 03:20:26PM +0530, Amitakhya Phukan wrote:
> > Hi all!
> >
> > I want to know how I can encrypt my /home partition which is inside a
> > Logical Volume to increase the security.
>
> Yes, make a backup of your /home, then format the partition with:
> 1. cryptsetup luksFormat /dev/volgroup/home
> 2. cryptsetup luksOpen /dev/volgroup/home chome
> 3. mke2fs -j -O dir_index -L /home /dev/mapper/chome
>
> Then add it to /etc/crypttab:
> chome /dev/volgroup/home none
>
> Then change /etc/fstab, the line that mounts /home, to mount from
> /dev/mapper/chome.
is there a guide somewhere to *all* of the solutions for encrypted
filesystems under fedora?
Not that I know of, but I found this on google:
http://www.redhatmagazine.com/2007/01/18/disk-encryption-in-fedora-past-p...
i haven't set one up for quite some time,
but i'd like to know what my options are. for example, AIUI, there is
Ooohh, a new acronym. I learn something new every day. ;)
also the ecryptfs technique which is different from the above, yes?
Yes, there are various techniques. cryptoloop, truecrypt, etc..
how does it differ?
luks/cryptsetup operate on a block-device level. Thus, every information
about files (name, size, owner, last changed/access time) are hidden.
cryptsetup uses the key as specified, while luks creates a random key
and protects it with passwords supplied by the user. Adding and removing
keys (passwords, in effect) is then possible without re-ciphering the
partition.
is one technologically superior to the other?
It depends on your needs. For swap, you must use a block-level method,
unless you're willing to use swap over files over ecryptfs (though I
wouldn't trust it not to deadlock at the moment).
Also, luks is currently supported by Fedora 8, in that attaching a
device (or clicking to mount an already attached device) will prompt for
the passphrase and mount it (though it sometimes fails to mount under
the directory named by the label of the filesystem, and ends mounting it
under label followed by "_").
can this encryption be done in place on an unencrypted filesystem?
Not crytpsetup, luks, cryptoloop and truecrypt. There may be others that
can, I'm not familiar with all implementations.
and can anyone stop the new england patriots juggernaut? so many
questions ...
I don't know. Who arey they? :)
--
lfr
0/0
9:51 a.m.
Robert P. J. Day worte:
<snip>
: is there a guide somewhere to *all* of the solutions for encrypted
: filesystems under fedora? i haven't set one up for quite some time,
: but i'd like to know what my options are. for example, AIUI, there is
: also the ecryptfs technique which is different from the above, yes?
:
: how does it differ? is one technologically superior to the other?
: can this encryption be done in place on an unencrypted filesystem?
: and can anyone stop the new england patriots juggernaut? so many
: questions ...
:
Though not a full answer to your question, this link:
<http://ecryptfs.sourceforge.net/ecryptfs-faq.html#novelty>
gives a nice comparison of the two major flavours of filesytem
encrption. Run down to:
Q: How does eCryptfs compare with other Linux disk encryption solutions?
on the above link.
For me, the main advantage of "Stacked Filesystem Encryption"
(e.g. eCryptfs) over the block-based methods is its selectivity. You
can encrypt any subset of a filesystem and leave less sensitive stuff
in the clear, whereas the block-based methods require the whole FS,
including meta-data to be encrypted. The latter has both advantages
and disadvantages. One disadvantage is that every single byte must be
en/decrypted, which affects performance. One advantage is that the
metadata of the filesystem is encrypted so stuff like the filenames
themselves are not in the clear. In certain cases, one's filenames, themselves,
contain sensitive info.
(E.g., plans_for_making_a_portable_thermonuclear_device.txt :-)
I used eCryptfs on a few sensitive directories of my system while
travelling through certain countries last summer. It was very easy to
setup and use after I read the well-written docs. Once the encryption
layer is mounted, access is entirely transparent.
Regarding the OP's original question, I don't see any reason why it
would not work in an LVM environment, but I have not actually tried it.
Dean
1:44 a.m.
On Fri, Jan 11, 2008 at 01:34:35AM +0900, Msquared wrote:
On Thu, Jan 10, 2008 at 03:44:00PM +0000, Luciano Rocha wrote:
> You misunderstand me. If you could add support to anaconda to install to
> a encrypted physical volume, tidy any patch of yours, and submit it
> upstream, more users will benefit. :)
Unfortunately, I don't have the time or the knowledge to properly
integrate it with Anaconda. I figure that this might make a good starting
point for someone who does, though...
anaconda in rawhide already contains support for encrypted root.. so it
should be in F9.
-- Pasi
10:34 a.m.
On Thu, Jan 10, 2008 at 03:44:00PM +0000, Luciano Rocha wrote:
You misunderstand me. If you could add support to anaconda to install
to
a encrypted physical volume, tidy any patch of yours, and submit it
upstream, more users will benefit. :)
Unfortunately, I don't have the time or the knowledge to properly
integrate it with Anaconda. I figure that this might make a good starting
point for someone who does, though...
Also, I misunderstood your webpage. As it mentions "encrypting
the root
filesystem" repeatedly, I assumed you encrypted single logical volumes,
not the whole physical volume. Encrypting the PV makes it more
interesting.
Yeah, I should probably update the docs a bit more. It's undergone many
re-writes as I added improvements to the patch and cleaned up the
documentaiton. :-)
Regards, Msquared...
9:44 a.m.
On Fri, Jan 11, 2008 at 12:31:25AM +0900, Msquared wrote:
> More information about the subject is always welcome. The ideal
thing
> would be for upstream support for the most usual methods mentioned
> (including during install).
I agree, but I wanted to play with it right now (couldn't wait for
something to be included), so I wrote my own patch based on some
information already on the net and improved it a lot.
You misunderstand me. If you could add support to anaconda to install to
a encrypted physical volume, tidy any patch of yours, and submit it
upstream, more users will benefit. :)
Also, I misunderstood your webpage. As it mentions "encrypting the root
filesystem" repeatedly, I assumed you encrypted single logical volumes,
not the whole physical volume. Encrypting the PV makes it more
interesting.
--
lfr
0/0
9:31 a.m.
On Thu, Jan 10, 2008 at 03:11:22PM +0000, Luciano Rocha wrote:
> http://www.msquared.id.au/articles/cryptroot/
Why does it require javascript?
I've used TiddlyWiki to write the article, which is basically a
wiki-in-a-single-page system. I find it a nice way to write documentation
for things.
> With my article, you don't need anything in crypttab
(including keys
> or other sensitive information).
I didn't see anything on that page that specified to the system to mount
the encrypted home on boot.
My article describes a way to encrypt the entire volume group, and a patch
to mkinitrd that decrypts the the volume group during boot.
Using LUKS for swap? It's an interesting idea, but I'd still
like to
nuke the contents of the swap on new boot.
Since the entire volume group is encrypted, so is swap. You can still
nuke the swap on each boot as well, if you like.
More information about the subject is always welcome. The ideal
thing
would be for upstream support for the most usual methods mentioned
(including during install).
I agree, but I wanted to play with it right now (couldn't wait for
something to be included), so I wrote my own patch based on some
information already on the net and improved it a lot.
Feel free to back up your data, try it out, and give me some feedback.
Regards, Msquared...
9:11 a.m.
On Thu, Jan 10, 2008 at 11:56:33PM +0900, Msquared wrote:
I know this thread is aging a bit, but I thought I'd post some
comments,
and link to an article I just put online:
http://www.msquared.id.au/articles/cryptroot/
Why does it require javascript?
> Then add it to /etc/crypttab:
> chome /dev/volgroup/home none
With my article, you don't need anything in crypttab (including keys or
other sensitive information).
I didn't see anything on that page that specified to the system to mount
the encrypted home on boot.
On Mon, Dec 24, 2007 at 09:11:17AM -0800, Alan wrote:
> Does encrypting swap interfere with hibernate or sleep mode on laptops?
> (Just asking in case I ever get sleep or hibernate working on my
> laptop.)
On Mon, Dec 24, 2007 at 05:43:10PM +0000, Luciano Rocha wrote:
> If you wish for a encrypted swap allowing suspend, you'll have to place
> a constant key in crypttab (which isn't secure, unless you also encrypt
> the root), and check if the resume scripts support that case or manually
> add it (not trivial).
If you encrypt the swap itself using a random key each boot, you will have
problems. If you use a constant key in crypttab, then you don't have any
security unless the crypttab itself (or rather, the filesystem that
contains it) is also encrypted.
Yes, I did mention just that.
If you use the method used in my article above, you should be able
to
hibernate and resume without any problems
Using LUKS for swap? It's an interesting idea, but I'd still like to
nuke the contents of the swap on new boot.
I've tried and it worked for me, even with a dual-boot. In fact,
I was
able to sleep Windows and resume Linux and vice versa for a much faster
way to switch from Windows to Linux (and vice versa). Of course, my
Windows partition isn't encrypted, but I don't use Windows as much.
More information about the subject is always welcome. The ideal thing
would be for upstream support for the most usual methods mentioned
(including during install).
--
lfr
0/0
8:56 a.m.
I know this thread is aging a bit, but I thought I'd post some comments,
and link to an article I just put online:
http://www.msquared.id.au/articles/cryptroot/
The article is titled "Encrypted root on Fedora & CentOS", and shows you
how to encrypt the entire hard drive. I'll address resume issues and
other things below...
On Mon, Dec 24, 2007 at 11:04:05AM +0000, Luciano Rocha wrote:
> I want to know how I can encrypt my /home partition which is
inside a
> Logical Volume to increase the security.
My article shows you how to encrypt the entire volume group.
Then add it to /etc/crypttab:
chome /dev/volgroup/home none
With my article, you don't need anything in crypttab (including keys or
other sensitive information).
On Mon, Dec 24, 2007 at 09:11:17AM -0800, Alan wrote:
Does encrypting swap interfere with hibernate or sleep mode on
laptops?
(Just asking in case I ever get sleep or hibernate working on my
laptop.)
On Mon, Dec 24, 2007 at 05:43:10PM +0000, Luciano Rocha wrote:
If you wish for a encrypted swap allowing suspend, you'll have to
place
a constant key in crypttab (which isn't secure, unless you also encrypt
the root), and check if the resume scripts support that case or manually
add it (not trivial).
If you encrypt the swap itself using a random key each boot, you will have
problems. If you use a constant key in crypttab, then you don't have any
security unless the crypttab itself (or rather, the filesystem that
contains it) is also encrypted.
If you use the method used in my article above, you should be able to
hibernate and resume without any problems
I've tried and it worked for me, even with a dual-boot. In fact, I was
able to sleep Windows and resume Linux and vice versa for a much faster
way to switch from Windows to Linux (and vice versa). Of course, my
Windows partition isn't encrypted, but I don't use Windows as much.
Regards, Msquared...
11:43 a.m.
On Mon, Dec 24, 2007 at 09:11:17AM -0800, Alan wrote:
> On Mon, Dec 24, 2007 at 03:20:26PM +0530, Amitakhya Phukan
wrote:
> There's little point in that, but it does add more security. Also, you
> should encrypt any swap and, if not encrypting /home, /tmp:
>
> Add to /etc/crypttab:
> 1. cswap /dev/volgroup/swap /dev/urandom swap
> 2. ctmp /dev/volgroup/tmp /dev/urandom tmp
> 3. cvartmp /dev/volgroup/vartmp /dev/urandom tmp
Does encrypting swap interfere with hibernate or sleep mode on laptops?
(Just asking in case I ever get sleep or hibernate working on my laptop.)
Yes. The swap partition is re-created each boot, with a random key, so
there's no way to get the old values (needed for resume).
If you wish for a encrypted swap allowing suspend, you'll have to place
a constant key in crypttab (which isn't secure, unless you also encrypt
the root), and check if the resume scripts support that case or manually
add it (not trivial).
--
lfr
0/0
11:11 a.m.
On Mon, Dec 24, 2007 at 03:20:26PM +0530, Amitakhya Phukan wrote:
There's little point in that, but it does add more security.
Also, you
should encrypt any swap and, if not encrypting /home, /tmp:
Add to /etc/crypttab:
1. cswap /dev/volgroup/swap /dev/urandom swap
2. ctmp /dev/volgroup/tmp /dev/urandom tmp
3. cvartmp /dev/volgroup/vartmp /dev/urandom tmp
Does encrypting swap interfere with hibernate or sleep mode on laptops?
(Just asking in case I ever get sleep or hibernate working on my laptop.)
5:24 a.m.
On Mon, 24 Dec 2007, Luciano Rocha wrote:
On Mon, Dec 24, 2007 at 03:20:26PM +0530, Amitakhya Phukan wrote:
> Hi all!
>
> I want to know how I can encrypt my /home partition which is inside a
> Logical Volume to increase the security.
Yes, make a backup of your /home, then format the partition with:
1. cryptsetup luksFormat /dev/volgroup/home
2. cryptsetup luksOpen /dev/volgroup/home chome
3. mke2fs -j -O dir_index -L /home /dev/mapper/chome
Then add it to /etc/crypttab:
chome /dev/volgroup/home none
Then change /etc/fstab, the line that mounts /home, to mount from
/dev/mapper/chome.
is there a guide somewhere to *all* of the solutions for encrypted
filesystems under fedora? i haven't set one up for quite some time,
but i'd like to know what my options are. for example, AIUI, there is
also the ecryptfs technique which is different from the above, yes?
how does it differ? is one technologically superior to the other?
can this encryption be done in place on an unencrypted filesystem?
and can anyone stop the new england patriots juggernaut? so many
questions ...
rday
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
5:04 a.m.
On Mon, Dec 24, 2007 at 03:20:26PM +0530, Amitakhya Phukan wrote:
Hi all!
I want to know how I can encrypt my /home partition which is inside a
Logical Volume to increase the security.
Yes, make a backup of your /home, then format the partition with:
1. cryptsetup luksFormat /dev/volgroup/home
2. cryptsetup luksOpen /dev/volgroup/home chome
3. mke2fs -j -O dir_index -L /home /dev/mapper/chome
Then add it to /etc/crypttab:
chome /dev/volgroup/home none
Then change /etc/fstab, the line that mounts /home, to mount from
/dev/mapper/chome.
Also, should I also encrypt the
main / partition??
There's little point in that, but it does add more security. Also, you
should encrypt any swap and, if not encrypting /home, /tmp:
Add to /etc/crypttab:
1. cswap /dev/volgroup/swap /dev/urandom swap
2. ctmp /dev/volgroup/tmp /dev/urandom tmp
3. cvartmp /dev/volgroup/vartmp /dev/urandom tmp
Then add to /etc/fstab:
/dev/mapper/cswap swap swap defaults 0 0
/dev/mapper/ctmp /tmp ext2 defaults 0 0
/dev/mapper/cvartmp /var/tmp ext2 defaults 0 0
There may be some graphical tool that allows all this, but I'm a
command-line person.
--
lfr
0/0
5947
days inactive
5968
days old
13 comments
8 participants
participants (8)
-
Alan -
Amitakhya Phukan -
Bill Case -
Dean S. Messing -
Luciano Miguel Ferreira Rocha -
Msquared -
Pasi Kärkkäinen -
Robert P. J. Day