RaTails – Draft High Level Steps

The purpose of this posting is to lay out the high level steps I see in making an analogue of Tails on the Raspberry Pi.

Partly this is a working document for the project of making something relatively secure and disposable that is ‘sort of like Tails’, and partly it is a set of links to things along that line that are interesting.

Any suggestions and / or folks pitching in most welcome.

Why Do This?

I’ve used my Raspberry Pi boards for several things now, and the Raspberry Pi Model 2 is “comfortable enough” for use as a disposable workstation (though you might want a bit more eventually). Single core (CPU) performance is a bit low for high demand tasks (like WordPress article editing – but some of that is network load as WP is very “chatty” with spell checkers constantly resending all the text). Multi-core performance ‘needs work’ on spreading task load around, but that’s not a big problem for most folks.

That means that you are $60 to Amazon and 1 day of assembly away from restoration of any “lost” (i.e. stolen by over zealous police) hardware. For typical uses, you could also have a stash of pre-built SD cards and just stick one in and go. Or download the image from some remote site, copy it to the card (with Windows or something like dd on Linux), and go. But then you end up in a recursion problem. You need to make the workstation to get the image to build the workstation…

And, if your ‘stuff’ was just taken (rather like what happened to Tallbloke ) and you know you are under surveillance (even if misguided) and perhaps with active Man In The Middle attacks on your downloads… well, you need some ‘other way’ to have internet presence without the probability of being compromised.

Progress To Date

Earlier we looked at how Tails is built and what if anything was being done by the Tails folks on the Raspberry Pi. First off, it’s a complicated build using at least 3 languages and git just to do a ‘roll your own’ OS. That’s a steeper curve than I can get done in short order and it is not well suited to a “newby” learning how to do things on a R.Pi. (That education goal being part of the whole reason for the Pi…)

While I’d love to just have a link to “install Tails on your Pi from here”, that isn’t in existence yet. The work to port Tails is larger than one part time guy wants to take on (i.e. me) and I think an incremental approach is more productive faster (though eventually a port of real Tails will obsolete it, the skill sets will be valuable in any case). So I also looked into alternatives. More on that below. But what has been done?

The basic hardware build and software configuration steps are documented and a draft generic build script written. While investigating precursor tech, like a ‘Live-CD’ build, I found that SliTaz has a ‘Live-CD’ like build for the R.Pi, but it isn’t ready for the Model 2 just yet. That could serve as a base for building a RaTails on the R.Pi B+ model, but don’t put it on your Model 2 without testing on a recyclable SD card… We have also seen how to put a file system into an encrypted file container on the Pi.

All of which brings us more or less up to date. Raspberry Pi built, configured, running and with the ability to put things into an encrypted container. Knowing that a ‘Live-CD’ build is possible, and that TOR The Onion Router, is already ported to the Raspberry Pi and running.

What’s Next?

This is a very high level list of what I see as ‘the next steps’. There are some dependencies in these, but often they can be done ‘out of order’. So some of this ordering represents personal interest, what I would want to have working first, or just random listing order. Feel free to go out of order. This isn’t a PERT chart with a critical path and dependencies, just a ‘ToDo List’.

1) Make a version of the OnionPi. I’ve already made a Pi that uses a WiFi dongle so this is mostly adding the Onion Router code to it. I put this first simply because it is ‘ready to go’ and will be immediately usable “as is”.

2) Boot it from an external USB drive. At that point you can have your “goods” on a ‘yankable’ USB stick and a very generic boot SD card in the Pi itself. This also lets you set up for boot-from network (and eventually from a remote site if you like). Berryboot looks like the way to go and doesn’t look too hard. This step could be done first, if desired.

3) Make that a ‘Live-CD’ type boot. This step starts to be a bit harder. I noticed that the Berryboot link shows Puppy as one of the OS types. As Puppy is a ‘live-CD’ boot, it might make sense to use it as the base and put the TOR router in place. That is an investigation step. “Roll your own” live-cd’ or start from pick one: {SliTaz | Puppy | …}. This step could be done first too, if desired. This involves using a read only squashfs file system to store the OS, and having a RAM based writable file system overlay using AUFS or similar on top (union file system) so it looks writable, but everything is really in a ram disk. It also means Raspian is out as it sometimes rolls to swap even with a 1 GB memory. Take 1/2 that for a RAM disk and you will ‘have issues’. So a smaller lighter distribution…

4) Add encryption to the boot. The Raspberry Pi has a rather different boot process. At some point it would be desirable to have the root / boot process be from encrypted disks, but it is a potential performance issue and complicated. I’d leave this for a later step; though Kali looks to have done it. It would be good to have a pen-testing station in your site anyway, so building one of these is a good idea in any case and in any order.

5) Amnesiac Build: Go through the system and weed out all the places it tries to remember things and squash them. At this point, reference to the Tails build is likely most efficient as they have done the work already. Things like making the browser not save cookies and not save cache pages or history. Can be done in any order, but likely better if done after base OS is settled in step 3 and many writes go to RAMdisk so volatile anyway.

6) Incognito Enforced Build: Go through the system and weed out all the places it tries to identify you and squash them. At this point, reference to the Tails build is likely most efficient as they have done the work already. Things like making the browser not tattle on you and not reporting things like all the WiFi stations your dongle can see and doesn’t present any useful identifiers of release info. Can be done in any order, but likely better if done after base OS is settled in step 3.

7) Harden the Operating System and Tools: If you don’t NEED it on the device to function, take it out. What is left needs to be tested and assured hardened. Firewall and protective suite tools tuned. So things like proper use of encryption, certs, key lengths, ciphers, ACLs etc. Use Kali for a first pass test of it. Can be started in any order, but must be completed after the system is stable and more or less finished. Create a build list that only includes the known needed elements and has ‘remove’ for everything else. Any specially modified code needs a repository built {somewhere} with source available for scrutiny. Ensure there are applications and pointers to things like encrypted email services, key generation and management, VPN to other countries, etc. All the applications you need, nothing that isn’t essential or secure.

8) QA and stress test cycle. Build a regression test suite for all known issues. (Perhaps start from the list of historical issues encountered by other releases such as Tails and Kali.). Ought to start collecting issues and data from day one, but this step never finishes as it is re-run and expanded with every new release and bug report.

9) Beta tester release. “In the wild” trials and fix cycle.

In Conclusion

Well, that’s what I’ve got so far. Kick it around. I’m quite happy to expand, contract, fix, and update.

My best guess is that I’ll get through about #5 and the real Tails release will get ported. Still, I think it worth the effort. There are times I’d like something a little more custom and flexible (so, for example, I can choose to save some cookies and and I can have a few desired but not quite mil-spec tools available) and Tails is not going to let me. Or I’d like a locked down amnesiac system, but don’t really need a full on TOR slow routing experience.

So IMHO being able to ‘pick and choose’ makes this worth it. It also means I’m not depending on the purity of some other soul or some download site for what I get. There is value in being different sometimes. For example, if “agencies” are watching for the fingerprint of folks using Tails or camping on TOR exit nodes, being a bit out of spec is a feature. (“Rotating shield frequencies Captain!”…) It can also “finger you” if you are the only person with that profile, and it means you are responsible for finding all the exposures in your ‘kit’, but having both modes available IMHO has merit.

I have a couple of other links on the tablet that need to be reviewed and I might add some more here later. Also note that each step needs a WBS Work Breakdown Structure done to sub-tasks. For example, a ‘live-CD’ type read-only build depends on having a RAMdisk based OS and a squashfs archive, though for a larger image on a USB drive, the squashfs is optional. Incognito Build depends on having an incognito hardened browser ala Tails. Each of those sub-tasks needs to be identified and then done. For a One Guy Shop that’s easy. You just do it and fix the errors, omissions, and aw shits in the QA cycle. For ‘more hands’ they need a bit more listing and handing off.

All of which says “expect things to grow in the comments” as that detail surfaces. Feel free to surface it ;-)

Subscribe to feed

Advertisement