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 |