On 6/18/07, n0dalus <n0dalus+redhat@xxxxxxxxx> wrote:
It generally starts to suck after the first password is entered and you have to have another. The great thing about encrypting / is config files. wpa_supplicant.conf which may have a key or password. DNS autoupdate scripts. There can be lots of private information for a personal workstation stored in /etc or in system scripts. In this system, only /boot needs to be unencrypted.
On 6/19/07, Bruno Wolff III <bruno@xxxxxxxx> wrote:
>
> I think waiting for a complete solution is not the way to proceed. There are
> several different steps involved with the solution. If some of the steps
> have workable solutions, getting them included in the distribution will
> help get them tested and allow other people to build upon the previous work.
> It might be hard to recruit people to do some of the things that will be
> eventually needed until there is some base functionallity for them to play
> with.
>
> You don't have to advertise full disk encryption for the masses as soon as
> there is some support for booting with an encrypted root partition.
>
Does full disk encryption have many advantages over directory-based
encryption? It seems like a lot less pain to be able to boot into X
and just have important directories encrypted.
It generally starts to suck after the first password is entered and you have to have another. The great thing about encrypting / is config files. wpa_supplicant.conf which may have a key or password. DNS autoupdate scripts. There can be lots of private information for a personal workstation stored in /etc or in system scripts. In this system, only /boot needs to be unencrypted.
One problem I see in both approaches is access control. Many computers
are used by more than one person, and instead of giving everyone the
one password (and having to change it whenever someone leaves the pool
of trusted people), it might be better to make sure these methods use
username/password combos which can be added and revoked.
Let me chime in here. LUKS supports up to 8 passwords on one volume. This isn't hard to manage as long as the person doesn't remove your other password. This approach has a couple of novel advantages.
With the LVM approach, swap is encrypted. It's encrypted on the layer under LVM, so you can hibernate on an encrypted volume. The restore operation is great. I know use the same approach with a larger swap, and use tmpfs backed /tmp to better utilized swap/temp and the extra beauty of suspending to encrypted swap.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
