/mandos/release

To get this branch, use:
bzr branch http://bzr.recompile.se/loggerhead/mandos/release

« back to all changes in this revision

Viewing changes to README

  • Committer: Teddy Hogeborn
  • Date: 2008-09-21 04:22:50 UTC
  • Revision ID: teddy@fukt.bsnet.se-20080921042250-r0qqjsbz2ulfo5le
* Makefile: Bug fix: fix syntax error.

* debian/control: Depend on "po-debconf".
  (mandos, mandos-client): Add "${misc:Depends}", used by
                           dh_installdebconf.

* debian/mandos-client.config: New; show note.
* debian/mandos-client.template: New.

* debian/mandos.README.Debian: New.

* debian/mandos.config: New; show note.
* debian/mandos.prerm: New; stop daemon.
* debian/mandos.template: New.

* debian/po/POTFILES.in: New.
* debian/po/sv.po: New.

* debian/rules (clean): Added "debconf-updatepo" as suggested by
                        po-debconf(7).
  (binary-common): Added "dh_installdebconf" to use "debian/*.config"
                   and "debian/*.template" files.

Show diffs side-by-side

added added

removed removed

Lines of Context:
49
49
  
50
50
  Now, of course the initial RAM disk image is not on the encrypted
51
51
  root file system, so anyone who had physical access could take the
52
 
  server offline and read the disk with their own tools to get the
53
 
  authentication keys used by a client.  *But*, by then the Mandos
54
 
  server should notice that the original server has been offline for
55
 
  too long, and will no longer give out the encrypted key.  The timing
56
 
  here is the only real weak point, and the method, frequency and
57
 
  timeout of the server’s checking can be adjusted to any desired
58
 
  level of paranoia
 
52
  Mandos client computer offline and read the disk with their own
 
53
  tools to get the authentication keys used by a client.  *But*, by
 
54
  then the Mandos server should notice that the original server has
 
55
  been offline for too long, and will no longer give out the encrypted
 
56
  key.  The timing here is the only real weak point, and the method,
 
57
  frequency and timeout of the server’s checking can be adjusted to
 
58
  any desired level of paranoia
59
59
  
60
60
  (The encrypted keys on the Mandos server is on its normal file
61
61
  system, so those are safe, provided the root file system of *that*
69
69
   to do.  An attacker would have to physically disassemble the client
70
70
   computer, extract the key from the initial RAM disk image, and then
71
71
   connect to a *still online* Mandos server to get the encrypted key,
72
 
   all *before* the Mandos server timeout kicks in and the Mandos
73
 
   server refuses to give out the key to anyone.
 
72
   and do all this *before* the Mandos server timeout kicks in and the
 
73
   Mandos server refuses to give out the key to anyone.
74
74
   
75
 
   Now, as the typical SOP seems to be to barge in and turn off and
76
 
   grab *all* computers, to maybe look at them months later, this is
77
 
   not likely.  If someone does that, the whole system *will* lock
 
75
   Now, as the typical procedure seems to be to barge in and turn off
 
76
   and grab *all* computers, to maybe look at them months later, this
 
77
   is not likely.  If someone does that, the whole system *will* lock
78
78
   itself up completely, since Mandos servers are no longer running.
79
79
   
80
80
   For sophisticated attackers who *could* do the clever thing, *and*
132
132
 
133
133
* Copyright
134
134
 
135
 
    Copyright (C) 2008 Teddy Hogeborn
136
 
                  2008 Björn Påhlsson
137
 
 
 
135
    Copyright © 2008 Teddy Hogeborn
 
136
                2008 Björn Påhlsson
 
137
  
138
138
** License:
139
 
 
 
139
   
140
140
   This program is free software: you can redistribute it and/or
141
141
   modify it under the terms of the GNU General Public License as
142
142
   published by the Free Software Foundation, either version 3 of the