10:03 a.m.
As an experiment I setup a machine with an encrypted root fs.
I have attached the patch for mkinitrd which I used. It is hard-coded for the
device names that I use (/dev/V0/fc2enc for the encrypted LVM volume) because
I couldn't think of a good way of storing this.
For production use this would need a --encrypt-root option or maybe reading
some sort of /etc/crypttab file and deducing that root encryption is needed.
Also with my patch you need to put "--with=dm-crypt --with=aes" on the
mkinitrd command-line.
To create the encrypted device you have to run
"cryptsetup -d /etc/root-key create crypto /dev/V0/fc2enc" to create the
encrypted device and then dd a file system of the same size
to /dev/mapper/crypto.
Finally I've created a statically linked version of cryptsetup for use in the
initrd and named it /usr/bin/cryptsetup.static . I've put the binary on
http://www.coker.com.au/crypt/ as a temporary measure for anyone who wants to
play with it. I'll release my code patches once I get them tidied up a bit.
Currently the statically linked version of cryptsetup is 780K in size. The
libdevmapper code drags in libselinux code which makes it overly large. I
think that perhaps we need to have a statically linked version of the
libdevmapper code without SE Linux support for use in the initrd (the SE
Linux policy is loaded by /sbin/init so there is no possibility of doing any
useful SE Linux stuff from inside the initrd).
I notice that /bin/lvm in the initrd (/sbin/lvm.static on the root fs) is over
1M in size and includes SE Linux code that is of no use in the initrd. Is
the statically linked version of lvm used for anything other than the initrd?
If not then we should just build it with no SE Linux support because once
again it can't do anything productive with SE Linux code in the initrd and it
just wastes space.
Please let me know what you think of these ideas. I would like to get some
feedback before I start filing bugzilla reports.
Finally please don't even think of testing this out on any machine that
contains important data. There are lots of ways that this can go wrong and
lose your data.
The aim of this work is to have a system that boots from removable media and
uses encryption for all block devices so that if it is stolen no data will be
lost and so someone who gets temporary access to the hardware will have a
much more difficult time of trying to crack it.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:23 a.m.
Hi,
First comment, this sounds cool. I suspect you want feedback so here it goes:
It is hard-coded for the sevice names that I use (/dev/V0/fc2enc for
the encrypted LVM volume)
This sounds very tied to fc2. I would recommend a name that's not tied to a
distribution release number.
Also with my patch you need to put "--with=dm-crypt
--with=aes" on the
mkinitrd command-line.
I don't see that in the patch you attached. The patch appears to remove the
normal block device stuff and replace it with yours. It should take command line
parameters as you say, and branch around normal stuff.
I'll release my code patches once I get them tidied up a bit.
Are they sync'ed with the patches current pending against mkinitrd? BZ #129673.
mkinitrd 4.0.5 doesn't work at all for many people. It is accidentally working
for everyone else. I have seen people leaving comments saying the patches I
submitted clear up their problems, so my guess is some or all of the patch will
get into mkinitrd 4.0.6 rsn.
Looking at bugzilla, there's already people trying to do the same thing. Look at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789
You may want to work with this effort.
Currently the statically linked version of cryptsetup is 780K in size.
I bet its not stripped either.
Good Luck with this.
-Steve Grubb
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
9:54 p.m.
Looking at bugzilla, there's already people trying to do the same
thing. Look at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789
You may want to work with this effort.
Yes, please. I am the author of that patch and I would love to have
some help in this effort!
I have a patch here locally (not yet in bugzilla) that works with mkinitrd
4.0.5 and the new initramfs code. I am working towards allowing folks
to unlock their root disk using a USB-device-hosted key, passphrase or
hexified key.
My patch requires crypsetup 0.2-pre1 for its libcryptsetup (no cryptsetup
binary on the initrd).
In order for this all to be taken seriously I think anaconda needs to be
modified to create an encrypted root at install time. The anaconda folks
have balked at additions in the past because the partition interface is
already quite complicated. So a clever and simple interface would
be necessary.
--
Mike
:wq
10:33 p.m.
On Mon, 16 Aug 2004 12:54, "W. Michael Petullo" <mike(a)flyn.org> wrote:
I have a patch here locally (not yet in bugzilla) that works with
mkinitrd
4.0.5 and the new initramfs code. I am working towards allowing folks
to unlock their root disk using a USB-device-hosted key, passphrase or
hexified key.
I don't think that a USB hosted key is worth doing. If you have only the key
on the USB device then someone who gains temporary access to your machine can
replace the kernel and/or initrd to compromise the machine later. If you are
using USB then I think it's best to boot from USB and read no unencrypted
data from the disk apart from the partition table.
It seems that all new hardware supports booting from USB and it seems
impossible to purchase a USB device smaller than 32M. So there's no reason
not to just boot from USB (IMHO).
In order for this all to be taken seriously I think anaconda needs to
be
modified to create an encrypted root at install time. The anaconda folks
have balked at additions in the past because the partition interface is
already quite complicated. So a clever and simple interface would
be necessary.
We can't expect anyone to do anything for anaconda until after mkinitrd etc
have already got support. The anaconda work may be the hardest part of this
and we can't expect them to do the hard work before we do the easy work!
Converting an installation that has an unencrypted root fs to have an
encrypted root fs is not particularly difficult once the mkinitrd issues are
solved. You just have to boot in single-user mode, create a new LV, run
cryptsetup, and then use dd to copy the data across.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:46 p.m.
On Mon, 16 Aug 2004 01:23, Steve G <linux_4ever(a)yahoo.com> wrote:
First comment, this sounds cool. I suspect you want feedback so here
it
goes:
>It is hard-coded for the sevice names that I use (/dev/V0/fc2enc
for
>the encrypted LVM volume)
This sounds very tied to fc2. I would recommend a name that's not tied to a
distribution release number.
Naturally. That just happens to be the name I used on my own system, it isn't
expected to work for anyone else. The Volume Group name "V0" is also
specific to my system. Anyone who wants to do the same will have to change
the device name as appropriate for their system.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789
You may want to work with this effort.
One thing that has just occurred to me is that using a /etc/crypttab file in
the same format as Debian will make things a lot easier. Here is a sample
crypttab:
# <target device> <source device> <key file> <options>
swap /dev/V0/swap /dev/random swap
root /dev/V0/fc2 /etc/root-key defaults
For example the above file would specify that the device /dev/mapper/swap
would be /dev/V0/swap encrypted with a key from /dev/random. In Debian the
"swap" parameter at the end of the line indicates that after the encrypted
device is setup the command "mkswap" should be run on it.
Now mkinitrd could check /etc/fstab, see that the root device
is /dev/mapper/root, look for the appropriate entry in /etc/crypttab then
know it needs to put /etc/root-key in the initrd and do the mapping
from /dev/V0/fc2 .
I've just added the above text to the bugzilla entry for 124789.
>Currently the statically linked version of cryptsetup is 780K in
size.
I bet its not stripped either.
No, that's 780K stripped!
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
11:10 p.m.
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789
>
> You may want to work with this effort.
One thing that has just occurred to me is that using a /etc/crypttab file in
the same format as Debian will make things a lot easier. Here is a sample
crypttab:
# <target device> <source device> <key file> <options>
swap /dev/V0/swap /dev/random swap
root /dev/V0/fc2 /etc/root-key defaults
Great point. This would also be more consistent with the encrypted swap
support that is being worked on. See the Bugzilla bug for a new patch
that uses /etc/crypttab and adds support for initrds that live on
removable devices and contain the FS key.
--
Mike
:wq
8:31 a.m.
On Mon, 16 Aug 2004 01:03:17 +1000, Russell Coker <russell(a)coker.com.au> wrote:
The aim of this work is to have a system that boots from removable
media and
uses encryption for all block devices so that if it is stolen no data will be
lost and so someone who gets temporary access to the hardware will have a
much more difficult time of trying to crack it.
If the goal is for an encrypted filesystem- why not just have a script
interface early on in the boot process to prompt for a password for
the encrypted file system - in order to mount the encrypted ones? Or
maybe a boot option grub could pass to the kernel to unencrypt the
partitions to mount? This is a concept- I know that a boot option
would be plaintext after the system booted, and you would not want to
save it in your grub config plaintext either.
In your design would you rely on physical secuity (not to lose the USB
key), the H.D. being encrypted, and UNIX security of the password- or
is there a pin/password similar to smart card and pin involved during
boot(multi factor authentication)?
I like the idea!
--Josiah
8:40 a.m.
On Mon, 16 Aug 2004 23:31, Josiah Royse <jroyse(a)gmail.com> wrote:
On Mon, 16 Aug 2004 01:03:17 +1000, Russell Coker
<russell(a)coker.com.au>
wrote:
> The aim of this work is to have a system that boots from
removable media
> and uses encryption for all block devices so that if it is stolen no data
> will be lost and so someone who gets temporary access to the hardware
> will have a much more difficult time of trying to crack it.
If the goal is for an encrypted filesystem- why not just have a script
interface early on in the boot process to prompt for a password for
the encrypted file system - in order to mount the encrypted ones? Or
I am thinking of making it an option to take a file of random data, a
user-entered password, or an XOR of both of them.
maybe a boot option grub could pass to the kernel to unencrypt the
partitions to mount? This is a concept- I know that a boot option
would be plaintext after the system booted, and you would not want to
save it in your grub config plaintext either.
I don't think that we will get such things in the kernel. It has to be an
initrd issue.
In your design would you rely on physical secuity (not to lose the
USB
key), the H.D. being encrypted, and UNIX security of the password- or
is there a pin/password similar to smart card and pin involved during
boot(multi factor authentication)?
A smart card can be lost just as easily as a USB key. The advantage of a
smart card is that someone can't steal the contents without stealing the card
(copying a USB key is easy if someone can get access for 20 seconds).
Once I get this basically working I'll probably investigate using a
smart-card. I have had a GPG smart card for almost a year, as soon as I
obtain a card reader I'll get it going.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
9:47 a.m.
On Mon, 16 Aug 2004 23:40:55 +1000, Russell Coker <russell(a)coker.com.au> wrote:
> If the goal is for an encrypted filesystem- why not just have a
script
> interface early on in the boot process to prompt for a password for
> the encrypted file system - in order to mount the encrypted ones? Or
I am thinking of making it an option to take a file of random data, a
user-entered password, or an XOR of both of them.
I like it! Basically a poor-man's smartcard of sorts. Much easier to
test/develop for since USB keys are easy to find.
Removing the USB key after boot in this senario would not affect it,
since the key is read once, correct? Down the road perhaps the UI
would be patched to recognize the removal of the smartcard/like device
and lock the screen. Just a thought!
--Josiah
9:54 a.m.
Removing the USB key after boot in this senario would not affect it,
since the key is read once, correct? Down the road perhaps the UI
would be patched to recognize the removal of the smartcard/like device
and lock the screen. Just a thought!
Pam_usb (http://www.pamusb.org/) does something like this. Pam_usb is
used to authenticate individual users against a USB drive but the xlock
concept is very similar to your idea.
--
Mike
9:36 p.m.
On Tue, 17 Aug 2004 00:47, Josiah Royse <jroyse(a)gmail.com> wrote:
On Mon, 16 Aug 2004 23:40:55 +1000, Russell Coker
<russell(a)coker.com.au>
wrote:
> > If the goal is for an encrypted filesystem- why not just
have a script
> > interface early on in the boot process to prompt for a password for
> > the encrypted file system - in order to mount the encrypted ones? Or
>
> I am thinking of making it an option to take a file of random data, a
> user-entered password, or an XOR of both of them.
I like it! Basically a poor-man's smartcard of sorts. Much easier to
test/develop for since USB keys are easy to find.
Yes.
Removing the USB key after boot in this senario would not affect it,
since the key is read once, correct? Down the road perhaps the UI
My idea is that the USB device would be used for /boot. So it would not need
to be installed all the time, but it would be required for kernel upgrades.
would be patched to recognize the removal of the smartcard/like
device
and lock the screen. Just a thought!
Eventually we'll get to such things. SE Linux is one of many parts of the Red
Hat security plan. Many more things will come in RHEL 5 and beyond.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:26 p.m.
On Mon, 2004-08-16 at 22:36, Russell Coker wrote:
On Tue, 17 Aug 2004 00:47, Josiah Royse <jroyse(a)gmail.com>
wrote:
> On Mon, 16 Aug 2004 23:40:55 +1000, Russell Coker <russell(a)coker.com.au>
wrote:
<snip>
> would be patched to recognize the removal of the smartcard/like
device
> and lock the screen. Just a thought!
This can easily be done via HAL and D-BUS in the future.
Eventually we'll get to such things. SE Linux is one of many
parts of the Red
Hat security plan. Many more things will come in RHEL 5 and beyond.
--
J5
7230
days inactive
7232
days old
11 comments
5 participants
participants (5)
-
John (J5) Palmieri -
Josiah Royse -
Russell Coker -
Steve G -
W. Michael Petullo