1 |
>> I am interested in working on a secure laptop meta-project. Laptop |
2 |
>> security is interesting because some amount of physical security must |
3 |
>> be addressed. Laptop theft is big buisiness, after all. |
4 |
>> |
5 |
>> A well designed laptop operating system would be centered around encrypted |
6 |
>> filesystems and would have many applications: |
7 |
>> |
8 |
>> 1. People who want to protect their personal data from theft. |
9 |
>> |
10 |
>> 2. Buisinesses that want to protect secrets stored on their fleet |
11 |
>> of laptops. |
12 |
>> |
13 |
>> 3. Military applications -- laptops are all over today's battlefield |
14 |
>> and a lucky ambush could easily reap classified information. |
15 |
>> |
16 |
>> 4. Etc... |
17 |
>> |
18 |
>> A company named NAH6 (http://www.nah6.com) has a product like this. |
19 |
>> They use Linux in order to boot Windows from an encrypted volume. |
20 |
>> I would like to focus on a Linux environment as an end. The idea is that a |
21 |
>> lost or stolen laptop will not give up any sensitive information. |
22 |
>> |
23 |
>> Here are the components I envision including their current status: |
24 |
>> |
25 |
>> 1. Encrypted root filesystem. The 2.6 Linux kernel and util-linux 2.12 |
26 |
>> will provide this using an encrypted loopback interface. A speedier |
27 |
>> compromise is to use encrypted home directories only. I maintain a PAM |
28 |
>> module, pam_mount, that mounts encrypted home directories transparently. [ I |
29 |
|
30 |
>> you don't mind a shameless plug, there is an article about pam_mount in the |
31 |
>> August Linux Journal. ] |
32 |
>> |
33 |
>> 2. Encrypted swap partition (or no swap at all). This is necessary because |
34 |
|
35 |
>> otherwise programs could swap secrets to a plaintext disk. The 2.6 Linux |
36 |
>> kernel's encrypted loopback interface can do this. |
37 |
>> |
38 |
>> 3. An inproved authentication system. Encryption algorithms are useless |
39 |
>> if a weak key is used. Therefore it may be desireable to authenticate |
40 |
>> when booting and mounting an encrypted root filesystem (or mounting an |
41 |
>> encrypted home directory) using a physical token or other strong means. |
42 |
>> |
43 |
>> 4. An intrusion detection system. |
44 |
>> |
45 |
>> 5. Obviously, otherwise hardened software. |
46 |
>> |
47 |
>> Comments? Has anyone else talked about this around here? |
48 |
|
49 |
> I haven't seen anything directly like this on the gentoo-hardened list |
50 |
> yet. I have seen the loopback encrypted filesystems and distro |
51 |
> discussions (nothing that isn't in the archives). |
52 |
|
53 |
> I haven't seen anything directly like this on the gentoo-hardened list |
54 |
> yet. I have seen the loopback encrypted filesystems and distro |
55 |
> discussions (nothing that isn't in the archives). |
56 |
|
57 |
Norman, you brought up some great points. I am familiar with TEMPEST, but am |
58 |
not far enough into this to start trying to mitigate its risk yet. |
59 |
|
60 |
I now have a few questions about the encrypted home directory scenario (most of |
61 |
root filesystem is plaintext). Basically, is it worth it vs. an encrypted root |
62 |
filesystem? Besides encrypting swap, one sticky point is encrypting /tmp. Here |
63 |
are a few potential solutions: |
64 |
|
65 |
1. Make /tmp an encrypted filesystem, generated at boot time with a random key |
66 |
(much like encrypted swap space). |
67 |
|
68 |
2. If you have enough memory and/or encrypted swap, use Linux's tmpfs. |
69 |
|
70 |
3. Implement per-user temporary directories in each user's encrypted $HOME. |
71 |
Obviously all applications must know to use $HOME/tmp instead of /tmp. This may |
72 |
be difficult to ensure. |
73 |
|
74 |
Plain text /tmp is of course bad because, for example, vi may leak secrets by |
75 |
creating recovery files there. So what is the best solution? Or are there too |
76 |
many potential loopholes when using encrypted home directories vs. encrypted |
77 |
root filesystem? |
78 |
|
79 |
-- |
80 |
Mike |
81 |
|
82 |
|
83 |
-- |
84 |
gentoo-hardened@g.o mailing list |