public inbox for gentoo-hardened@lists.gentoo.org
 help / color / mirror / Atom feed
From: Joshua Brindle<method@gentoo.org>
To: gentoo-hardened@gentoo.org, "Waters, Boyd"<bwaters+moz@cv3.cv.nrao.edu>
Subject: Re: [gentoo-hardened] Hard Disk Encryption
Date: Thu, 5 Jun 2003 22:29:00 -0500	[thread overview]
Message-ID: <20030605T222933Z_B95E00150000@gentoo.org> (raw)

I'll top post since this is fairly long.

You are right, it is a huge issue for physical security and something
that many of us think about all the time. 

For those who have not seen the project homepage 
(http://www.gentoo.org/proj/en/hardened) I suggest you go, in
the 'planned subprojects' list I have mentioned both cryptoapi
and FiST (the link is there for more information). I know that selinux
has gotten the most attention within the project and also on this
list but there are some things to consider. 

First, we've been working on other things like propolice integration 
and grsecurity acl's. Solar, a new hardened developer has put
 together a really nice system for installing grsecurity acl's for installed
 software. 

Second, we have many projects that we'd like to do (see list on the page)
but as we are a fairly new project we don't have a huge amount of 
manpower to make it happen. If you are interested in putting together
a very solid implementation for this sort of thing then by all means
drop by #gentoo-hardened on irc.freenode.net and chat with us :) .

Third, SELinux was the first subproject we actually started working
on so naturally it's ahead of everything else.

I hope that everyone would look at the webpage and speak up if
they are capable of doing anything that we have planned or even 
security related projects which we haven't thought of.

Thank you, and I would love to have strong crypto block support 
in Gentoo, and I'm sure many others would as well :)

Joshua Brindle

>One aspect of computer data security that has become important to me
>is the obfuscation of data on the computer hard disk. This will slow
>down data retrieval by unauthorized people who manage to gain
>unrestricted physical access to the computer.
>
>Such a scenario is becoming more likely with the rise in popularity of
>laptop computers as primary workstation platforms. (I am writing this
>on a laptop that is the only machine I use.) If someone walks off with
>your laptop computer, then a robust access-control-list (ACL) policy
>is not going to do you any good; one may simply mount the hard disk
>via a less-secure system and have unrestricted access to the data.
>
>I decided to encrypt the entire disk on my computer: not just per-user
>partitions, but the entire root (and swap, too). The reason for this
>is that I could not think of a straightforward way to prevent
>important security tokens from landing in non-user areas, such as /etc
>or /var/lib.
>
>Critics of whole-disk encryption claim that it's a waste of time to
>encrypt common files, such as the ~2GB of files that comprise the
>libraries and binaries of a typical Linux installation. Or worse, that
>such an approach can lead to known-plaintext attacks. Well: I don't
>see a significant performance penalty, and cipher-block-chaining mode
>can make known-plaintext attacks more difficult.
>
>I have been using an encrypted root hard disk for a year. I back up my
>data to other encrypted volumes. No data loss so far. I use the
>kerneli CryptoAPI with 2.4.20.
>
>This thread on Gentoo Forums has seen recent activity, discussing the
>use of loop-AES for hard disk encryption with 2.4.x kernels:
>http://forums.gentoo.org/viewtopic.php?t=31363 
>
>My recent efforts have focused on deployment of encrypted hard disks
>in the 2.5.x kernels. The CryptoAPI is now part of the mainline Linux
>tree, but loop device encryption is not.
>
>An encrypted loopback block device driver has been implemented by
>CryptoAPI developers as a thin layer on top of the new Linux 2.5 block
>device system. I believe this approach may be best for the long term,
>but there is relatively little discussion of this on the
>cryptoapi-devel mailing list. And using this driver requires patches
>to util-linux that have not yet been incorporated into the standard
>util-linux distribution.
>
>In contrast, the loop-AES implementation has been ported to the 2.5.x
>kernels; this is a simple port of the 2.4.x block device to the 2.5
>kernel. It may not be able to take advantage of the scatterlist
>blockdev optimizations that the cryptoAPI incorporates. But it has a
>responsive developer, and it seems to work better with recent versions
>of util-linux (2.11z).
>
>I have not yet been able to tweak my init RAMdisks that I used for
>2.4.x root encryption so that they will successfully boot a 2.5
>system. But I think I am close to doing so: another week or two at the
>most.
>
>I believe that block-level encryption is a far better approach for
>on-the-disk data protection than a stacked filesystem such as
>FiST. Creation of a FiST encryption layer would be upside-down, I
>think: a standard filesystem such as e2fs that "hosts" encrypted
>data. With FiST, the atomic units exposed to the encryption layer are
>file-system units: file names, dirents, etc. With block-level
>encryption, you encrypt blocks: opaque chunks of bytes. (FiST might be
>very powerful for implementing policy-based access, though...)
>
>I am very pleased by the Gentoo-Hardened effort. I think that the
>current focus on learning about SELinux is vital: since security is a
>_process_ rather than a _technology_, we need to learn how to
>implement meaningful security policies on our Gentoo boxes.
>
>I think that this Disk Encryption is completely orthogonal to this
>effort: advances in this arena will not interfere with whatever
>security policies are developed by the SELinux initiative. Block-level
>encryption is (almost) completely transparent to a running system, so
>ACLs and SELinux PSMs can run on top of such with *no* modification.
>
>I think that other enabling technologies like token-based access
>control (smart cards, USB dongles) fall somewhere in the middle: the
>technology (device drivers) needs to be developed, but security
>policies should be likewise developed to take advantage of these.
>
>So:
>I am working on block-level encryption. I think it is particluarly
>important for laptop users. I would like to co-ordinate my efforts
>with the Gentoo-Hardened project.
>
>Cheers!
>
>-- boyd
>watersb on Gentoo Forums
>
>
>
>
>--
>gentoo-hardened@gentoo.org mailing list
>


--
gentoo-hardened@gentoo.org mailing list


             reply	other threads:[~2003-06-06  3:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-06  3:29 Joshua Brindle [this message]
2003-06-06 20:46 ` [gentoo-hardened] Marketing Hardened Gentoo Gavin Vess
2003-06-07  1:36   ` Boyd Waters
2003-06-07  2:40     ` John Robinson
2003-06-07  3:21       ` Boyd Waters
2003-06-07 19:04         ` Gavin Vess
2003-06-08  1:04           ` Chris PeBenito
2003-06-08 21:16             ` Boyd Waters
2003-06-09 13:41               ` stephen white
2003-06-07  4:45   ` Jeffrey Lim
  -- strict thread matches above, loose matches on Subject: below --
2003-06-06  2:56 [gentoo-hardened] Hard Disk Encryption Boyd Waters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030605T222933Z_B95E00150000@gentoo.org \
    --to=method@gentoo.org \
    --cc=bwaters+moz@cv3.cv.nrao.edu \
    --cc=gentoo-hardened@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox