Re: Root filesystem encryption update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2007-06-19 at 09:36 +0930, n0dalus wrote:
> 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.

Well, encrypting subtrees (directories) is technically harder and the
code for doing so isn't 100% there yet.  eCryptFS is working on it, but
there's still some work to be done for it to be there.  I tend to think
that it has a lot of advantages because of the ability to be on the
running system, etc.  Then you can really
* encrypt home directories on a per-user basis with per-user keys
* have subdirectories in your home directory with a different passphrase
if they're more security sensitive
* prompt for passphrases at log-in time when we have a full system
* use polyinstantiated /tmp (which has other security advantages) that's
actually under the user's home directory
* encrypt swap just as a block device with a random key -- this still
needs fiddling to figure out how hibernate works

> 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.

The idea with pretty much all of the methods is that you can have
multiple keys defined and then delete keys at any point.

Jeremy

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux