CentOS

Centos 5.3 includes Ext4 and improved support for encrypted file systems but it appears to be aimed at laptop/desktop systems, in that a password must be entered at boot time.

Is it possible to have a server with an encrypted root file system boot up without entering a password?

Mandos will do it...
http://wiki.fukt.bsnet.se/wiki/Mandos
...by serving up the password from another server...
http://packages.debian.org/squeeze/mandos
...to a client loaded into the initial RAM disk environment...
http://packages.debian.org/squeeze/mandos-client
...but it's not available on CentOS, and is only in Debian unstable.

Is there a similar (or any) solution for CentOS?

In particular, I'm envisaging encrypted virtual machines being served passwords from their virtual host.

Alternatively, the data that *really* needs to be protected could be encrypted while the system core remains unencrypted. But then the keys to decrypt the file system must be stored in the unencrypted portion, so this is not an effective method. Right?

Thanks,
Julez

To clarify...

I'm using CentOS 5.2 and I'd like to encrypt the file system now, on CentOS 5.2.

The reason I mentioned 5.3 is

1) If encrypting the file system is going to be a lot easier on 5.3 then I'd rather wait for it. But as far as I know, the new version doesn't have any bearing on the boot password issue.

2) There will probably be more people trying to encrypt the file system when 5.3 arrives, so it would be useful to have the answer (if there is one) here in the forum or in a HowTo.

- Julez

> I'm envisaging encrypted virtual machines being served passwords from their virtual host.
For virtual machines, it can be some by adapting the script that boots up the guest VMs.

The key can be read from a file on a local drive or USB memory stick (which is the same thing really). So it should be possible for the host to make the key available on a virtual hard drive or usb memory stick. Then when the guest has booted (e.g. it allows an ssh login) the key can be deleted or the virtual disk/memory stick holding the key can be ejected.

Alternatively, the key could be made temporarily available to the guest on a samba share. This would have the advantage that the key is not made available to the process that starts the VMs. But I don't know if the key can be read from a Samba share, as that would require networking, which may not have been started by that point.

I haven't attempted either method yet, but I will make the script available when I have it working. If you get there first then please post the script here.

Thanks,
Julez

[quote]
Julez wrote:
[...]
Is it possible to have a server with an encrypted root file system boot up without entering a password?

Mandos will do it...
http://wiki.fukt.bsnet.se/wiki/Mandos
...by serving up the password from another server...
http://packages.debian.org/squeeze/mandos
...to a client loaded into the initial RAM disk environment...
http://packages.debian.org/squeeze/mandos-client
...but it's not available on CentOS, and is only in Debian unstable.

Is there a similar (or any) solution for CentOS?[/quote]

(Mandos co-author here.)

I don't think so. The problem with both CentOS and Fedora is that there is no way (that I can see) to make Mandos a part of the boot process. The [font=Courier]/init[/font] in the initial RAM disk image has no hooks to make Mandos provide the password, and the script which creates both [font=Courier]/init[/font] and the rest of the initial RAM disk image, [font=Courier]/sbin/mkinitrd[/font], has no hooks for affecting the contents of [font=Courier]/init[/font] or for making the Mandos client binaries even exist in the initial RAM disk image.

So the only way I can see to use Mandos (or anything like it) is to change the initial RAM disk image after it's created, by unpacking it, modifying it and re-packing it, either manually or with a probably very brittle script.

By contrast, both Debian and Ubuntu has hooks [i]all over[/i] that Mandos can just hook into, to be run at initrd creation time, at boot time, and at password querying time. This makes for an extremely flexible and powerful system, and no other OS (that I know of) has such hooks for Mandos to use. Until this changes, I do not foresee Mandos running out of the box on anything else than Debian-based distros. It is of course always possible to manually put Mandos into the initrd and modify the [font=Courier]/init[/font] script by hand, and some people may do this, but it would not be a scalable solution.

[quote]
In particular, I'm envisaging encrypted virtual machines being served passwords from their virtual host.

Alternatively, the data that [i]really[/i] needs to be protected could be encrypted while the system core remains unencrypted. But then the keys to decrypt the file system must be stored in the unencrypted portion, so this is not an effective method. Right?
[/quote]

This is not the normal envisioned usage situation for Mandos, so you might find a more appropriate solution to your problem. I am curious why the disks need to be encrypted at all if you trust the virtual machine server - the exact threat model you are operating under will dictate your solution. Without knowing this, I can do little, but one immediate thought is to have the virtual machine server decrypt some devices and hand the virtual machines ready-made decrypted devices.

(Please do not reply here, as I don't follow this forum. Use the [url=http://mail.fukt.bsnet.se/cgi-bin/mailman/listinfo/mandos-dev]Mandos mailing list[/url] to further discuss the use of Mandos.)