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