1 Linux:dm=crypt Encrypted Home Directories
2 =========================================
3 :author: Aaron Ball
4 :email: nullspoon@iohq.net
5
6
7 == {doctitle}
8
9 There are three primary methods for encrypting one's home directory seamlessly
10 in Linux: http://en.wikipedia.org/wiki/Dm-crypt[dm-crypt],
11 http://ecryptfs.org/[eCryptFS], and http://www.arg0.net/encfs[EncFS]. All
12 differences aside, this post will cover dm-crypt (as indicated by the title of
13 course). A few things to note before going forwards though. First, this method
14 is by no means the standard. I'm not even sure if there is a standard way to do
15 this. This is just the way I've done it and it has worked out swimingly thus
16 far on more than one computer. Secondly, my method detailed here will use
17 something called http://code.google.com/p/cryptsetup/[LUKS]. I highly recommend
18 this, if not just for convenience. While it does have its pitfalls, they
19 shouldn't be too bad if you keep a backup of your data. Really though, when
20 encrypting, you should _always_ keep more than one copy of your data in case
21 something goes awry.
22
23 Before proceeding, here is a list of what this will give you once completed, so
24 you can decide if this is what you want before reading this monolithic post .
25
26 . Users will each have their own encrypted home directory.
27 * Each home directory will be unlocked using the user's own password.
28 * Users have complete storage anonimity. Even root can't tell how many
29 files they are storing, filenames, or even how much data they have unless
30 the user is logged in at the time of inspection.
31 . User's home directories will be seamlessly decrypted and mounted at login.
32 . Users will have their own virtual device, so they will have a storage
33 "quota". To expand it, the virtual device needs to be extended on its own
34 (some might consider this cumbersome).
35
36
37 [[setup]]
38 == Setup
39
40 This should be relatively simple. Install a package likely called *cryptsetup*
41 (most of the mainstream distros should have it). This is the utility we will be
42 using to manage dm-crypt volumes. Note also that cryptsetup can be used for
43 managing more than just dm-crypt and luks. It also works with Truecrypt (much
44 to my excitement a few months ago when I needed to extract some data from a
45 Truecrypt volume, but didn't want to install it becuase of all the suspicion
46 surrounding it lately).
47
48 [[modifying-pam]]
49 === Modifying PAM
50
51 [[etcpam.dsystem-auth]]
52 ==== /etc/pam.d/system-auth
53
54 This piece assumes your distribution puts this file here and that it is named
55 this. Unfortuantely, I can't really write this part to be distribution-agnostic
56 as most of them do this differently to an extent. The contents of the file
57 will likely look similar, despite its name. For anyone wondering though, this
58 section is written from an Arch Linux instance.
59
60 Open /etc/pam.d/system-auth in your favorite editor. Be sure to do this either
61 with sudo or as root or you won't be able to save your changes.
62
63 Here we need to put in calls to a module called pam_mount.so so it will be
64 called at the right time to pass the user's password to the mount command,
65 allowing for seamless encrypted home directory mounting. Pay attention to where
66 the calls to pam_mount.so are. Order is very important in this file.
67
68 NOTE: Many distributions use eCryptFS as their default encryption for home
69 directories. They do it this way as well, but using pam_ecryptfs.so
70 instead of pam_mount.so.
71
72 ./etc/pam.d/system-auth
73 ----
74 #%PAM-1.0
75
76 auth required pam_unix.so try_first_pass nullok
77 auth optional pam_mount.so
78 auth optional pam_permit.so
79 auth required pam_env.so
80
81 account required pam_unix.so
82 account optional pam_permit.so
83 account required pam_time.so
84
85 password optional pam_mount.so
86 password required pam_unix.so try_first_pass nullok sha512 shadow
87 password optional pam_permit.so
88
89 session optional pam_mount.so
90 session required pam_limits.so
91 session required pam_unix.so
92
93 session optional pam_permit.so
94 ----
95
96
97 [[etcsecuritypam_mount.conf.xml]]
98 ==== /etc/security/pam_mount.conf.xml
99
100 This is the configuration file used by pam_mount when the user logs in.
101 Depending on your distribution, it may or may not already be set up the way we
102 need for this.
103
104 Just before the +</pam_mount>+ at the end of the xml file, insert the following
105 lines.
106
107 ./etc/security/pam_mount.conf.xml
108 ----
109 ...
110
111 <volume fstype="crypt" path="/home/.%(USER)" mountpoint="/home/%(USER)" options="space_cache,autodefrag,compress=lzo" />
112 <mkmountpoint enable="1" remove="true" />
113
114 </pam_mount>
115 ----
116
117 Before proceeding, there are a couple of assumptions that I need to mention
118 about the way I do this here.
119
120 . My home directories are all formatted with btrfs. If you're not using that,
121 then remove the *autodefrag,compress=lzo* piece in the options section.
122
123 . The encrypted block device files are located at */home/.USERNAME* (note the
124 dot).
125
126
127 [[creating-an-encrypted-home-per-user]]
128 === Creating an Encrypted Home Per User
129
130 The creations of each user's home directory has a few fairly simple steps [if
131 you've been using linux command line for a bit]. For the sake of more succinct
132 directions, here we will assume a username of __kevin__.
133
134 . Allocate user's encrypted home space (assuming 15 gigs)
135 * +dd if=/dev/zero of=/home/.kevin bs=1G count=15+
136 * This command writes 15 gigabytes of zeros to one file, /home/.kevin
137
138 . Encrypt the user's home device
139 * +cryptsetup luksFormat /home/.kevin+
140 * This command will require the user to enter _their_ password when
141 prompted after running the command, as that will be what is passed to
142 the file container on login.
143
144 . Open the user's new home device (you'll need the user to enter their password
145 again)
146 * +cryptsetup luksOpen /home/.kevin kevin+
147 * This will only be needed the first time around. Kevin can't use this
148 yet becasue it doesn't have a filesystem and it can't be mounted for the
149 same eason.
150
151 . Format the opened dm-crypt device
152 * +mkfs.btrfs /dev/mapper/kevin+
153 * This is assuming you want to use btrfs. Otherwise you'd use mkfs.ext4
154 or some other filesystem of choice.
155
156 . Cleanup
157 * +cryptsetup luksClose kevin+
158 * In this case, _kevin_ can be the alias given to the opened device on
159 luksOpen. You can also provide its path at /dev/mapper/kevin.
160
161
162 [[how-it-works]]
163 == How it Works
164
165 When a user logs in, they type their username and password. Those are passed to
166 pam, which verifies the user's identity using the _pam_unix.so_ module. If the
167 credentials provided by the user are correct, the next step is to pass that
168 username and password to the _pam_mount.so_ module. This module runs the
169 commands dictated in the pam_mount.conf.xml. The commands pam mount runs (as
170 per our earlier configuration) are effectively
171
172 ----
173 cryptsetup luksOpen /home/.$\{username} _home__$\{username} mount /dev/mapper/_home__$\{username} /home/%\{username}
174 ----
175
176 Those commands open the dot file (/home/.username) for the given user with the
177 recently provided password. It then mounts that user's decrypted dot file at
178 the user's home directory (/home/username).
179
180
181 [[backups]]
182 == Backups
183
184 This kind of encryption makes backups a bit difficult to pull off as the
185 administrator. Because you don't have each user's password, you can't back up
186 their data. This leaves you with one option - back up the encrypted block
187 devices themselves. Depending on how much space each user is given, this can
188 take a long time (though rsync helps significantly with that) and a lot of
189 space. This is the downside to
190 https://wiki.archlinux.org/index.php/Encryption#Block_device_encryption[block
191 device encryption].
192 https://wiki.archlinux.org/index.php/Encryption#Stacked_filesystem_encryption[Stacked
193 encryption] though, while rumored to be less secure for various reasons, allows
194 administrators access to encrypted verions of each user's data. With stacked
195 encryption, each individual file's contents are encrypted, but the user's
196 filenames, paths, and file sizes are still accessible to the administrator(s)
197 (hence the rumored security flaw).
198
199 As a user though (if you're using this on your laptop for instance), backups
200 are simple because the data itself is available to you (you have the password
201 after all). This however assumes you have user rights on a remote server to
202 rsync your data to. Even if the remote server has the same dm-crypt setup,
203 rsync still sends your credentials, so your data can go from an encrypted
204 laptop/desktop to an encrypted server.
205
206
207
208 Category:Storage
209 Category:Security
210 Category:Linux
211
212 // vim: set syntax=asciidoc:
|
