Gentoo Archives: gentoo-hardened

From: Joshua Brindle <method@g.o>
To: gentoo-hardened@g.o, "Waters, Boyd" <bwaters+moz@×××××××××××.edu>
Subject: Re: [gentoo-hardened] Hard Disk Encryption
Date: Fri, 06 Jun 2003 03:29:44
Message-Id: 20030605T222933Z_B95E00150000@gentoo.org
1 I'll top post since this is fairly long.
2
3 You are right, it is a huge issue for physical security and something
4 that many of us think about all the time.
5
6 For those who have not seen the project homepage
7 (http://www.gentoo.org/proj/en/hardened) I suggest you go, in
8 the 'planned subprojects' list I have mentioned both cryptoapi
9 and FiST (the link is there for more information). I know that selinux
10 has gotten the most attention within the project and also on this
11 list but there are some things to consider.
12
13 First, we've been working on other things like propolice integration
14 and grsecurity acl's. Solar, a new hardened developer has put
15 together a really nice system for installing grsecurity acl's for installed
16 software.
17
18 Second, we have many projects that we'd like to do (see list on the page)
19 but as we are a fairly new project we don't have a huge amount of
20 manpower to make it happen. If you are interested in putting together
21 a very solid implementation for this sort of thing then by all means
22 drop by #gentoo-hardened on irc.freenode.net and chat with us :) .
23
24 Third, SELinux was the first subproject we actually started working
25 on so naturally it's ahead of everything else.
26
27 I hope that everyone would look at the webpage and speak up if
28 they are capable of doing anything that we have planned or even
29 security related projects which we haven't thought of.
30
31 Thank you, and I would love to have strong crypto block support
32 in Gentoo, and I'm sure many others would as well :)
33
34 Joshua Brindle
35
36 >One aspect of computer data security that has become important to me
37 >is the obfuscation of data on the computer hard disk. This will slow
38 >down data retrieval by unauthorized people who manage to gain
39 >unrestricted physical access to the computer.
40 >
41 >Such a scenario is becoming more likely with the rise in popularity of
42 >laptop computers as primary workstation platforms. (I am writing this
43 >on a laptop that is the only machine I use.) If someone walks off with
44 >your laptop computer, then a robust access-control-list (ACL) policy
45 >is not going to do you any good; one may simply mount the hard disk
46 >via a less-secure system and have unrestricted access to the data.
47 >
48 >I decided to encrypt the entire disk on my computer: not just per-user
49 >partitions, but the entire root (and swap, too). The reason for this
50 >is that I could not think of a straightforward way to prevent
51 >important security tokens from landing in non-user areas, such as /etc
52 >or /var/lib.
53 >
54 >Critics of whole-disk encryption claim that it's a waste of time to
55 >encrypt common files, such as the ~2GB of files that comprise the
56 >libraries and binaries of a typical Linux installation. Or worse, that
57 >such an approach can lead to known-plaintext attacks. Well: I don't
58 >see a significant performance penalty, and cipher-block-chaining mode
59 >can make known-plaintext attacks more difficult.
60 >
61 >I have been using an encrypted root hard disk for a year. I back up my
62 >data to other encrypted volumes. No data loss so far. I use the
63 >kerneli CryptoAPI with 2.4.20.
64 >
65 >This thread on Gentoo Forums has seen recent activity, discussing the
66 >use of loop-AES for hard disk encryption with 2.4.x kernels:
67 >http://forums.gentoo.org/viewtopic.php?t=31363
68 >
69 >My recent efforts have focused on deployment of encrypted hard disks
70 >in the 2.5.x kernels. The CryptoAPI is now part of the mainline Linux
71 >tree, but loop device encryption is not.
72 >
73 >An encrypted loopback block device driver has been implemented by
74 >CryptoAPI developers as a thin layer on top of the new Linux 2.5 block
75 >device system. I believe this approach may be best for the long term,
76 >but there is relatively little discussion of this on the
77 >cryptoapi-devel mailing list. And using this driver requires patches
78 >to util-linux that have not yet been incorporated into the standard
79 >util-linux distribution.
80 >
81 >In contrast, the loop-AES implementation has been ported to the 2.5.x
82 >kernels; this is a simple port of the 2.4.x block device to the 2.5
83 >kernel. It may not be able to take advantage of the scatterlist
84 >blockdev optimizations that the cryptoAPI incorporates. But it has a
85 >responsive developer, and it seems to work better with recent versions
86 >of util-linux (2.11z).
87 >
88 >I have not yet been able to tweak my init RAMdisks that I used for
89 >2.4.x root encryption so that they will successfully boot a 2.5
90 >system. But I think I am close to doing so: another week or two at the
91 >most.
92 >
93 >I believe that block-level encryption is a far better approach for
94 >on-the-disk data protection than a stacked filesystem such as
95 >FiST. Creation of a FiST encryption layer would be upside-down, I
96 >think: a standard filesystem such as e2fs that "hosts" encrypted
97 >data. With FiST, the atomic units exposed to the encryption layer are
98 >file-system units: file names, dirents, etc. With block-level
99 >encryption, you encrypt blocks: opaque chunks of bytes. (FiST might be
100 >very powerful for implementing policy-based access, though...)
101 >
102 >I am very pleased by the Gentoo-Hardened effort. I think that the
103 >current focus on learning about SELinux is vital: since security is a
104 >_process_ rather than a _technology_, we need to learn how to
105 >implement meaningful security policies on our Gentoo boxes.
106 >
107 >I think that this Disk Encryption is completely orthogonal to this
108 >effort: advances in this arena will not interfere with whatever
109 >security policies are developed by the SELinux initiative. Block-level
110 >encryption is (almost) completely transparent to a running system, so
111 >ACLs and SELinux PSMs can run on top of such with *no* modification.
112 >
113 >I think that other enabling technologies like token-based access
114 >control (smart cards, USB dongles) fall somewhere in the middle: the
115 >technology (device drivers) needs to be developed, but security
116 >policies should be likewise developed to take advantage of these.
117 >
118 >So:
119 >I am working on block-level encryption. I think it is particluarly
120 >important for laptop users. I would like to co-ordinate my efforts
121 >with the Gentoo-Hardened project.
122 >
123 >Cheers!
124 >
125 >-- boyd
126 >watersb on Gentoo Forums
127 >
128 >
129 >
130 >
131 >--
132 >gentoo-hardened@g.o mailing list
133 >
134
135
136 --
137 gentoo-hardened@g.o mailing list

Replies

Subject Author
[gentoo-hardened] Marketing Hardened Gentoo .. Gavin Vess <Gavin@××××.com>