Dtyjlui

I will be on vacations and where I go, there will be a computer in my room. I don't know what type of computer, how old, what specs, nothing. But probably it will have Windows installed and probably I will only be able to login as restricted user.

Both are things I don't like.

So I thought I could bring my own portable Ubuntu on a bootable 8GB USB stick with me. But you see that 8GB is not really much and USB is also not the fastest thing on the world, especially if the computer might only have 2.0 ports.

Therefore I would love if I could outsource swap and probably even some data or system parts to the HDD of this computer, but I don't want to modify the existing system in any way, so repartitioning is not an option.

I think creating a virtual file system image file inside the existing file system and mounting that one would be best. It should be encrypted though.

And no, a simple live USB is not enough, it has at least to be persistent. However, the HDD using feature should be there too.

So how could I best set this up, a system installed on a USB stick that can create and mount an encrypted virtual disk on an existing file system without irreversibly modifying it? Detailed step-by-step guides appreciated, wherever the installation differs from a normal desktop installation.

Regular file systems

1. 
   

   Create a file on the existing file system on the internal drive of the computer (probably NTFS) for each (encrypted) partition, that you want to create, assuming the internal file system is mounted at /mnt/internal-drive and 1 GiB as the desired size of the resulting partition:

   
   
   

   head -c 1G < /dev/zero > /mnt/internal-drive/some/arbitrary/path/partition.img
   
   

   
   
   

   If you want a nice progress indicator you can use pv:

   
   
   

   head -c 1G < /dev/zero | pv -s 1g -pterab > .../partition.img
   
   

   
   
   

   If you want to create a partition based on a sparse file instead, use truncate(1) with the --size (shorthand: -s) option to specify the size in bytes:

   
   
   

   truncate -s 1073741824 .../partition.img
   
   

   
   
   

   Sparse files are fast to create and only occupy as much space as needed on the underlying file systems, but can become slow to access due to fragmentation. Some older file systems like FAT don't support sparse files. NTFS does.

   
   


2. 
   

   Initialise the desired file system in the just created file, e. g. ext4:

   
   
   

   mkfs -t ext4 [FS-OPTIONS...] .../partition.img
   
   

   
   
   

   The file system initialiser may ask you to confirm to create a file system inside a regular file or may even refuse to do so, unless you set a --force flag or similar.

   
   


3. 
   

   Create a loop device backed by the partition file and mount it. Reasonably recent versions of mount(8), can do this in one step with the loop option:

   
   
   

   mount -t ext4 -o defaults,loop[,FS-OPTIONS...] .../partition.img /mnt/my-partition
   
   

   
   



4. Enjoy!

Swap partitions

1. Like step 1 above, but you probably want to avoid the sparse option.



2. 
   

   Initialize the swap file:

   
   
   

   mkswap /mnt/internal-drive/some/arbitrary/path/swap.img
   
   

   
   


3. 
   

   Swap-on:

   
   
   

   swapon [OPTIONS...] /mnt/internal-drive/some/arbitrary/path/swap.img
   
   

   
   

Block-level encryption

Just like in the previous sections, regular files can be used pretty much like block devices. So you can use cryptsetup(8), crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8) as you normally would, since they create loop devices for regular files automatically:

1. Like step 1 in the above sections.



2. 
   

   If you want to use LUKS to manage your encrypted partition, initialize it:

   
   
   

   cryptsetup luksFormat .../partition.img [OPTIONS...]
   
   

   
   


3. 
   

   Open the partition with your chosen encryption type and options:

   
   
   

   cryptsetup open .../partition.img <NAME> --type <DEVICE_TYPE> [OPTIONS...]
   
   

   
   
   

   Where <NAME> is the name of the dm-crypt mapping to create for the partition and <DEVICE_TYPE> is luks, if you have created a LUKS wrapper in step 2, or plain for a plain dm-crypt partition. (cryptsetup supports other device types, but they're either legacy or for TrueCrypt compatibility.)

   
   


4. 
   

   The encrypted partition is now available at /dev/mapper/<NAME>.

   
   
   
   
   

   • You can create and mount file systems on it like on any block device as outlined in the above sections starting in step 2, or

   
   
   • 
     

     you can create a partition table inside it with your favourite partition manager, if you want to wrap multiple partitions inside it without having to supply the same passphrase multiple times for them individually:

     
     
     

     fdisk /dev/mapper/<NAME>
     
     

     
     
     

     Ask the kernel to re-read the partition table and to repopulate the device node files in /dev:

     
     
     

     partprobe /dev/mapper/<NAME>
     
     

     
     
     

     You now have the individual partitions available at /dev/mapper/<NAME>1 and so forth.

     
     
   
   
   
   

Mounting at boot

You can create fstab (and crypttab) entries for theses partitions just like you would normally, but with the loop option like above. File-based swap spaces don't need special mount options. You just need to take care to mount the underlying filesystem on the internal drive before these new partitions. E. g.:

LABEL=Windows    /mnt/internal-drive    ntfs    defaults    0  2

/mnt/internal-drive/some/arbitrary/path/home.img    /home    ext4     defaults,loop    0  3

/mnt/internal-drive/some/arbitrary/path/swap.bin    none     swap     sw    0  0

Destroying the file system afterwards

Short version: Don't! Use encryption and destroy the key.

Long version: Overwriting or "shredding" of individual files works under the assumption, that the file never occupied other drive sectors than it currently does (e. g. because the file system or one of its maintenance tools (e. g. de-fragmentation) decided to relocate them) and that no file data ever leaks into file system meta-data section (e. g. like during journalling). These assumptions may hold under most circumstances for older, non-journalling file systems (FAT, ext2). For NTFS, ext3/4 and HFS+ they don't hold reliably except under rare, impractical/unrealistic conditions.

You can go as far as to overwrite all unallocated sectors in addition to the sector currently occupied by the drive image file. Microsoft's cipher.exe can do this for NTFS, which supposedly catches almost all sectors, that may still contain left-overs of your precious file system image.