/mandos/trunk : revision 493

To get this branch, use:

bzr branch
http://bzr.recompile.se/loggerhead/mandos/trunk

« back to all changes in this revision

Viewing changes to intro.xml

Committer: Teddy Hogeborn
Date: 2011-08-08 21:12:37 UTC
Revision ID: teddy@fukt.bsnet.se-20110808211237-jejsz5brjytrjot8

* Makefile (DOCS): Added "intro.8mandos".
(intro.8mandos, intro.8mandos.xhtml): New.
* README: Replaced text with link, reference and short summary.
* intro.xml: New.
* mandos-clients.conf.xml (SEE ALSO): Added "intro(8mandos)".
* mandos-ctl.xml (SEE ALSO): - '' -
* mandos-keygen.xml (SEE ALSO): - '' -
* mandos-monitor.xml (SEE ALSO): - '' -
* mandos.conf.xml (SEE ALSO): - '' -
* mandos.xml (SEE ALSO): - '' -
* plugin-runner.xml (SEE ALSO): - '' -
* plugins.d/askpass-fifo.xml (SEE ALSO): - '' -
* plugins.d/mandos-client.xml (SEE ALSO): - '' -
* plugins.d/password-prompt.xml (SEE ALSO): - '' -
* plugins.d/plymouth.xml (SEE ALSO): - '' -
* plugins.d/splashy.xml (SEE ALSO): - '' -
* plugins.d/usplash.xml (SEE ALSO): - '' -

files added:
intro.xml

files modified:
Makefile

README

TODO

mandos-clients.conf.xml

mandos-ctl.xml

mandos-keygen.xml

mandos-monitor.xml

mandos.conf.xml

mandos.xml

plugin-runner.xml

plugins.d/askpass-fifo.xml

plugins.d/mandos-client.xml

plugins.d/password-prompt.xml

plugins.d/plymouth.xml

plugins.d/splashy.xml

plugins.d/usplash.xml

Show diffs side-by-side

added added

removed removed

intro.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"

"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [

<!ENTITY TIMESTAMP "2011-08-08">

<!ENTITY % common SYSTEM "common.ent">

%common;

<title>Mandos Manual</title>

<productname>Mandos</productname>

<productnumber>&version;</productnumber>

<date>&TIMESTAMP;</date>

<firstname>Björn</firstname>

<surname>Påhlsson</surname>

<email>belorn@fukt.bsnet.se</email>

</address>

</author>

<firstname>Teddy</firstname>

<surname>Hogeborn</surname>

<email>teddy@fukt.bsnet.se</email>

</address>

</author>

</authorgroup>

<holder>Teddy Hogeborn</holder>

<holder>Björn Påhlsson</holder>

</copyright>

<xi:include href="legalnotice.xml"/>

</refentryinfo>

<refentrytitle>intro</refentrytitle>

<manvolnum>8mandos</manvolnum>

</refmeta>

<refname>intro</refname>

Introduction to the Mandos system

</refpurpose>

</refnamediv>

<title>DESCRIPTION</title>

<para>

This is the the Mandos system, which allows computers to have

encrypted root file systems and at the same time be capable of

remote and/or unattended reboots.

</para>

<para>

The computers run a small client program in the initial RAM disk

environment which will communicate with a server over a network.

All network communication is encrypted using TLS. The clients

are identified by the server using an OpenPGP key; each client

has one unique to it. The server sends the clients an encrypted

password. The encrypted password is decrypted by the clients

using the same OpenPGP key, and the password is then used to

unlock the root file system, whereupon the computers can

continue booting normally.

</para>

</refsect1>

<title>INTRODUCTION</title>

<para>

You know how it is. You’ve heard of it happening. The Man

comes and takes away your servers, your friends’ servers, the

servers of everybody in the same hosting facility. The servers

of their neighbors, and their neighbors’ friends. The servers

of people who owe them money. And like

<emphasis>that</emphasis>, they’re gone. And you doubt you’ll

ever see them again.

</para>

<para>

That is why your servers have encrypted root file systems.

However, there’s a downside. There’s no going around it:

rebooting is a pain. Dragging out that rarely-used keyboard and

screen and unraveling cables behind your servers to plug them in

to type in that password is messy, especially if you have many

servers. There are some people who do clever things like using

serial line consoles and daisy-chain it to the next server, and

keep all the servers connected in a ring with serial cables,

which will work, if your servers are physically close enough.

There are also other out-of-band management solutions, but with

<emphasis>all</emphasis> these, you still have to be on hand and

manually type in the password at boot time. Otherwise the

server just sits there, waiting for a password.

</para>

<para>

Wouldn’t it be great if you could have the security of encrypted

100

root file systems and still have servers that could boot up

101

automatically if there was a short power outage while you were

102

asleep? That you could reboot at will, without having someone

103

run over to the server to type in the password?

104

</para>

105

<para>

106

Well, with Mandos, you (almost) can! The gain in convenience

107

will only be offset by a small loss in security. The setup is

108

as follows:

109

</para>

110

<para>

111

The server will still have its encrypted root file system. The

112

password to this file system will be stored on another computer

113

(henceforth known as the Mandos server) on the same local

114

network. The password will <emphasis>not</emphasis> be stored

115

in plaintext, but encrypted with OpenPGP. To decrypt this

116

password, a key is needed. This key (the Mandos client key)

117

will not be stored there, but back on the original server

118

(henceforth known as the Mandos client) in the initial RAM disk

119

image. Oh, and all network Mandos client/server communications

120

will be encrypted, using TLS (SSL).

121

</para>

122

<para>

123

So, at boot time, the Mandos client will ask for its encrypted

124

data over the network, decrypt it to get the password, use it to

125

decrypt the root file, and continue booting.

126

</para>

127

<para>

128

Now, of course the initial RAM disk image is not on the

129

encrypted root file system, so anyone who had physical access

130

could take the Mandos client computer offline and read the disk

131

with their own tools to get the authentication keys used by a

132

client. <emphasis>But</emphasis>, by then the Mandos server

133

should notice that the original server has been offline for too

134

long, and will no longer give out the encrypted key. The timing

135

here is the only real weak point, and the method, frequency and

136

timeout of the server’s checking can be adjusted to any desired

137

level of paranoia

138

</para>

139

<para>

140

(The encrypted keys on the Mandos server is on its normal file

141

system, so those are safe, provided the root file system of

142

<emphasis>that</emphasis> server is encrypted.)

143

</para>

144

</refsect1>

145

146

147

<title>FREQUENTLY ASKED QUESTIONS</title>

148

<para>

149

Couldn’t the security be defeated by…

150

</para>

151

152

<title>Grabbing the Mandos client key from the

153

initrd <emphasis>really quickly</emphasis>?</title>

154

<para>

155

This, as mentioned above, is the only real weak point. But if

156

you set the timing values tight enough, this will be really

157

difficult to do. An attacker would have to physically

158

disassemble the client computer, extract the key from the

159

initial RAM disk image, and then connect to a <emphasis>still

160

online</emphasis> Mandos server to get the encrypted key, and do

161

all this <emphasis>before</emphasis> the Mandos server timeout

162

kicks in and the Mandos server refuses to give out the key to

163

anyone.

164

</para>

165

<para>

166

Now, as the typical procedure seems to be to barge in and turn

167

off and grab <emphasis>all</emphasis> computers, to maybe look

168

at them months later, this is not likely. If someone does that,

169

the whole system <emphasis>will</emphasis> lock itself up

170

completely, since Mandos servers are no longer running.

171

</para>

172

<para>

173

For sophisticated attackers who <emphasis>could</emphasis> do

174

the clever thing, <emphasis>and</emphasis> had physical access

175

to the server for enough time, it would be simpler to get a key

176

for an encrypted file system by using hardware memory scanners

177

and reading it right off the memory bus.

178

</para>

179

</refsect2>

180

181

182

<title>Replay attacks?</title>

183

<para>

184

Nope, the network stuff is all done over TLS, which provides

185

protection against that.

186

</para>

187

</refsect2>

188

189

190

<title>Man-in-the-middle?</title>

191

<para>

192

No. The server only gives out the passwords to clients which

193

have <emphasis>in the TLS handshake</emphasis> proven that

194

they do indeed hold the OpenPGP private key corresponding to

195

that client.

196

</para>

197

</refsect2>

198

199

200

<title>Physically grabbing the Mandos server computer?</title>

201

<para>

202

You could protect <emphasis>that</emphasis> computer the

203

old-fashioned way, with a must-type-in-the-password-at-boot

204

method. Or you could have two computers be the Mandos server

205

for each other.

206

</para>

207

<para>

208

Multiple Mandos servers can coexist on a network without any

209

trouble. They do not clash, and clients will try all

210

available servers. This means that if just one reboots then

211

the other can bring it back up, but if both reboot at the same

212

time they will stay down until someone types in the password

213

on one of them.

214

</para>

215

</refsect2>

216

217

218

<title>Faking ping replies?</title>

219

<para>

220

The default for the server is to use

221

<quote><literal>fping</literal></quote>, the replies to which

222

could be faked to eliminate the timeout. But this could

223

easily be changed to any shell command, with any security

224

measures you like. It could, for instance, be changed to an

225

SSH command with strict keychecking, which could not be faked.

226

Or IPsec could be used for the ping packets, making them

227

secure.

228

</para>

229

</refsect2>

230

</refsect1>

231

232

233

<title>SECURITY</title>

234

<para>

235

So, in summary: The only weakness in the Mandos system is from

236

people who have:

237

</para>

238

239

240

<para>

241

The power to come in and physically take your servers,

242

243

</para>

244

</listitem>

245

246

<para>

247

The cunning and patience to do it carefully, one at a time,

248

and <emphasis>quickly</emphasis>, faking Mandos

249

client/server responses for each one before the timeout.

250

</para>

251

</listitem>

252

</orderedlist>

253

<para>

254

While there are some who may be threatened by people who have

255

<emphasis>both</emphasis> these attributes, they do not,

256

probably, constitute the majority.

257

</para>

258

<para>

259

If you <emphasis>do</emphasis> face such opponents, you must

260

figure that they could just as well open your servers and read

261

the file system keys right off the memory by running wires to

262

the memory bus.

263

</para>

264

<para>

265

What Mandos is designed to protect against is

266

<emphasis>not</emphasis> such determined, focused, and competent

267

attacks, but against the early morning knock on your door and

268

the sudden absence of all the servers in your server room.

269

Which it does nicely.

270

</para>

271

</refsect1>

272

273

274

<title>PLUGINS</title>

275

<para>

276

In the early designs, the

277

<citerefentry><refentrytitle>mandos-client</refentrytitle

278

><manvolnum>8mandos</manvolnum></citerefentry> program (which

279

retrieves a password from the Mandos server) also prompted for a

280

password on the terminal, in case a Mandos server could not be

281

found. Other ways of retrieving a password could easily be

282

envisoned, but this multiplicity of purpose was seen to be too

283

complex to be a viable way to continue. Instead, the original

284

program was separated into <citerefentry><refentrytitle

285

>mandos-client</refentrytitle><manvolnum>8mandos</manvolnum

286

></citerefentry> and <citerefentry><refentrytitle

287

>password-prompt</refentrytitle><manvolnum>8mandos</manvolnum

288

></citerefentry>, and a <citerefentry><refentrytitle

289

>plugin-runner</refentrytitle><manvolnum>8mandos</manvolnum

290

></citerefentry> exist to run them both in parallel, allowing

291

the first successful plugin to provide the password. This

292

opened up for any number of additional plugins to run, all

293

competing to be the first to find a password and provide it to

294

the plugin runner.

295

</para>

296

<para>

297

Four additional plugins are provided:

298

</para>

299

300

301

<term>

302

<citerefentry><refentrytitle>plymouth</refentrytitle>

303

<manvolnum>8mandos</manvolnum></citerefentry>

304

</term>

305

306

<para>

307

This prompts for a password when using <citerefentry>

308

<refentrytitle>plymouth</refentrytitle><manvolnum

309

>8</manvolnum></citerefentry>.

310

</para>

311

</listitem>

312

</varlistentry>

313

314

<term>

315

<citerefentry><refentrytitle>usplash</refentrytitle>

316

<manvolnum>8mandos</manvolnum></citerefentry>

317

</term>

318

319

<para>

320

This prompts for a password when using <citerefentry>

321

<refentrytitle>usplash</refentrytitle><manvolnum

322

>8</manvolnum></citerefentry>.

323

</para>

324

</listitem>

325

</varlistentry>

326

327

<term>

328

<citerefentry><refentrytitle>splashy</refentrytitle>

329

<manvolnum>8mandos</manvolnum></citerefentry>

330

</term>

331

332

<para>

333

This prompts for a password when using <citerefentry>

334

<refentrytitle>splashy</refentrytitle><manvolnum

335

>8</manvolnum></citerefentry>.

336

</para>

337

</listitem>

338

</varlistentry>

339

340

<term>

341

<citerefentry><refentrytitle>askpass-fifo</refentrytitle>

342

<manvolnum>8mandos</manvolnum></citerefentry>

343

</term>

344

345

<para>

346

To provide compatibility with the "askpass" program from

347

cryptsetup, this plugin listens to the same FIFO as

348

askpass would do.

349

</para>

350

</listitem>

351

</varlistentry>

352

</variablelist>

353

<para>

354

More plugins can easily be written and added by the system

355

administrator; see the section called "WRITING PLUGINS" in

356

<citerefentry><refentrytitle>plugin-runner</refentrytitle>

357

<manvolnum>8mandos</manvolnum></citerefentry> to learn the

358

plugin requirements.

359

</para>

360

</refsect1>

361

362

363

364

<para>

365

<citerefentry><refentrytitle>mandos</refentrytitle>

366

<manvolnum>8</manvolnum></citerefentry>,

367

<citerefentry><refentrytitle>mandos.conf</refentrytitle>

368

<manvolnum>5</manvolnum></citerefentry>,

369

<citerefentry><refentrytitle>mandos-clients.conf</refentrytitle>

370

<manvolnum>5</manvolnum></citerefentry>,

371

<citerefentry><refentrytitle>mandos-ctl</refentrytitle>

372

<manvolnum>8</manvolnum></citerefentry>,

373

<citerefentry><refentrytitle>mandos-monitor</refentrytitle>

374

<manvolnum>8</manvolnum></citerefentry>,

375

<citerefentry><refentrytitle>plugin-runner</refentrytitle>

376