On Wed, Sep 19, 2001 at 11:20:47PM +0100, Dale Amon wrote:
> > 1. # dd if=/dev/zero of=/SWAP bs=1M count=64
>
> I think we've been over this before, but perhaps a return...
> I also usually use /dev/zero to init the fs, however doesn't
> this necessarily mean that when blocks are written under
> crypto, those blocks will stick out like sore thumbs to
> someone who wants to actually try to recover data?
I understand your point, but over time I don't think it will matter,
because each boot (or running of the cron script) will reinitialise the
device with a new password.
But since I rarely exceed 40MB or so of swap in use, I should probably
format my swap partitions (which formerly were unencrypted) with output
from /dev/random or urandom. And in that case you probably wouldn't be
able to tell where the written blocks end and the random output starts
(unless of course you were keeping records of the state of the swap
device between initialisations, which would not be practical for an
attacker to manage.)
Of course an attacker can assume that the first blocks are the encrypted
ones, because every reinitialisation probably has the kswapd start at
the beginning of the device. Now *that* would be a good idea: rewrite
kswapd to keep a pointer (where to start writing in the device) between
sessions on a particular device. (Of course if the pointer is maintained
in a file on disk, you are back to the same place WRT security concerns.
Unless you randomise the pointer in your shutdown, that is. :)
> I see that Jarl overwrites with zeroes 20 times on startup
> in an attempt to destroy information from the previous
> session; however reboot time would seem a bit late to
To me (at least thinking about my own threat model) this kind of caution
doesn't seem necessary. The most common "brute force" attack is to apply
brutality to someone who refuses to divulge his passphrase. Since in the
case of the swap devices, I wouldn't even know my own passphrase, I am
immune from that kind of attack. (They can get brutal, but they won't
get the passphrase.)
My threat model is not the TLA spooks; it's incredibly stupid and
incompetent local thugs. They're probably not even smart enough to hire
a good consultant. :) Maybe if you think you're likely to arouse the
interest of a national gov't, these extra precautions would be worth the
effort and inconvenience.
> do this. Many machines never power down except for a
> hardware change or kernel update. Even my home workstation
> hasn't been rebooted in 10 days.
That's why I like the idea of reinitializing the encrypted swap daily.
New passphrases bury the needle deeper in the haystack. Realistically,
even if important information can be found on the swap device, it won't
be a simple matter to distinguish WHICH bits are important. Suppose my
PGP passphrase is there. Unless it's somehow flagged ("Hey look, the
following string is this poor dumb guy's $PGPPASS!" :) there are still
many possible strings among that data.
This reminds me of another thing I like about how this loop encryption
works. The losetup and cipher driver do not tell you if you've made a
mistake. You don't find out until you try to access the filesystem (or
whatever is on the device.) That would complicate the job of a brute
force attacker.
> Perhaps there should be a stop script in which the
> "overwrite ten times" occurs instead/also.
A good, but potentially inconvenient idea. That could make shutdowns
take a lot longer. But if your security is worth it ...
> Is there any *practicable* way to randomize the swap
> file contents before we losetup?
Again, I think this only needs to be done once, so that's practicable.
> Another question: if you run this script and there is
> a swap space already created, your password will go
> into it, so you had better make sure this is the
> first swap on. This would catch either script.
My cron script will take down the swap devices (I will have two) one at
a time. swapoff checks the pages and writes any which are worth keeping
to the other device. When that is finished the device is detached,
reencrypted with a new password, mkswap'ed and reactivated. Then the
process is repeated for the other device.
I don't have that one written yet, but it should be pretty simple (most
of the same stuff I have in rc.local already.)
> Second point; when you have multiple swap spaces are
> the later ones actually getting used or are they just
> cathing overflow? I've not looked closely, but when I
This is configurable by setting the priority. If you don't specify the
priority I think each new swap device has lower priority, which means it
gets started when the previous one is full.
The trick is to specify identical priorities for your swap devices. I
don't know if it matters what number you use. I use "1" for all of mine,
and they are all being used.
# swapon -s
Filename Type Size Used Priority
/dev/loop7 partition 65528 3244 1
/dev/loop5 partition 124984 84 1
/dev/loop6 partition 64504 3236 1
The loop7 device was the SWAP file and loop6 was the partition in my
original example. At the time of activating those two, swap use in the
other partition was abou 24MB, and when I swapoff'ed it, 5 and 6 each
inherited a little more than 3MB. Then I losetup'ed that partition as
loop5 and activated it. Since then the few new swap pages have been
distributed about equally among all three.
> was having a serious memory leak problem with xplanetbg
> I added swap spaces and it looked very much like thay
> filled sequentially. In other words Rob, can you
> confirm that swapping to your crypto swap space actually
> occured? Did you try to swapoff the noncrypto one?
After making that post I did that, then walked away from the machine. It
hasn't had much demand since then. As you see I have 84KB (21 pages) in
use on the last unencrypted one.
> And last, a not specifically crypto question.... does
> anyone know a way to include a swap *file* in /etc/fstab?
Of course. Simply use the filename in place of the device name. Be sure
that the filesystem it's on is mounted before the "swapon -a" in your
boot sequence.
Note that this only applies to an unencrypted swap file. An encrypted
one would have to be addressed by the name of its loop device.
> (obviously you cannot create a loopback mount in fstab,
> but could do the losetup early in boot and name it in
> fstab)
That's how I'm planning to try it. Actually I think I will disable the
distro's "swapon -a" and put it after my losetup commands in rc.local.
Here's what it looks like for now:
### 2001/09/19: encrypted swap devices
# load the main cryptoapi module
modprobe cryptoloop
# swap partitions hda4 hdc2
for PART in a4 c2
do
# loop devices 6 & 7
for DEV in 6 7
do
dd if=/dev/urandom bs=1 count=32 2> /dev/null | \
uuencode -m - | cut -c8-29 | tail -2 | head -1 | \
losetup -e blowfish -k128 -p0 /dev/loop$DEV /dev/hd$PART
mkswap /dev/hd$PART
done
done
# activate swap devices
swapon -a
We'll see how that does. I haven't tested it yet but it looks like it
should work. :)
Thanks for the reply, Dale.
Rob - /dev/rob0
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
