Topic: OS for "Ultimate" security (Read 3217 times)

A little snipped corroboration on the SELinux support issue from jgarzik:

Well, I'm happy for any and all discussion, although my intended focus was the specific security merits of using one OS over another, not so much the implications of the way you tier the access to different wallets with air gaps etc. I'm kind of making the assumption that MacOS and Windows are to be avoided. And I'm looking to safeguard against any threat to my private or public keys, from a lone hacker all the way up to some government agency.


One thing I'd like to hear from real Linux afficionados: SELinux? Do we care about this? Just about every guide or article I've read on it says "Do not turn it on (enforcing mode), unless you're prepared for some serious config tweaking to make sure you don't get access denials when trying to do some regular thing".

And I'm not sure that the standard build of bitcoind or Armory has been written to take account of interacting with the SELinux permissions system.

Also, "written by evil NSA" FUD. Or not FUD? I can't honestly say I have a clear picture, although common sense is telling me probably just FUD, as even the most fringe of Linux distros are not removing it from their codebase. Could there be some overall design flaw that can be exploited? Why would NSA want to contribute to securing machines, when they're raison d'etre is to break into secure computing systems? They've been outed as having weakened the form of ECDSA that we don't sign transactions with, after all. But then again, they also played a significant role in the establishment of SHA-2, and that's got a very solid reputation from a lengthy period of study.

I mistunderstood the topic here, I thought Carlton was looking for online capacity. Granted we have a inhouse Raspbian build for Armory now, it wouldn't be too hard to get it online on a Pi, assuming you sync BitcoinQt and build Armory's DB on another machine, but I would recommend against it regardless =P.

To clear all misunderstandings, I use my Pi as my offline Armory signer.

I think you are the first one here suggesting Armory on a Raspi in online mode ;-)
Awesome that it's working, though! Armory really came a long way since needing 4+gb Ram!

Ente

Raspbian for online Armory? Ouch! Already takes me like 2 minutes to sign a single transaction with 1 output and change 0.0

If it's just a question of missing extra hardware for a dedicated offline computer, how about a rasbpi and Armory? One of the things on my to-do-list..
Cheap, tiny, easy to hide.

With much about any reasonable linux platform, I don't think a software attack is the biggest thread.
If it's a dedicated Armory system (no games, no surfing, no unnecessary software at all), all regular malware is out already.
This leaves only linux core bugs, exploits and backdoors (and bitcoind exploits, of course). Those are rare and expensive, unlikely to be used on a large scale against many users.
Now only obscure channels are left. Hypothetical weak RNG in SSL, bugged ECC, backdoored AES, backdoors in closed source drivers, in hardware, in the CPU itself. This stuff is, if it exists (what we have to assume here), only known to the NSA and maybe, if at all, comparable organisations (yeah, right). They wouldn't even make use of those even for the complete control of all Bitcoins in existance. It would not pay off to risk those channels becoming public.

Sorry, I kept talking and talking, I am heading in the wrong direction here.

I agree, after using a dedicated linux box, the next attack scenario would be closed source blobs. Well, ignoring dirty tricks like bugging software on-the-fly while you download it to your machine..
About using a platform with "open source drivers available" hardware only: You can define which repositories to use on all distros, you should be able to use open-sourced-only and compile-yourself repositories only. There are several distros which, by default, use FOSS only. Most closed-source-drivers aren't even needed here, like the 3D part of a graficcard, audio and so on.
So yes, I believe you don't even have to use special hardware or a special distro to be fully open source.

I plan to use said Armory on a Rasbpi soon. Then I don't need to make sure the hardware, drivers, linux, additional software, encryption algorithms, bitcoind and Armory are without bugs and backdoors, as I have (more or less) removed any possible way for data to leak out at all.
If then someone does the $5 wrench attack on me, I'll happily surrender the one bitcoin I own.

Sorry again, I feel this is not an answer you are looking for. My suggestion: Define your scenario. What to protect from? What are the accepted uncertainities, what are the accepted limits?
Besides that: Use linux, don't do anything else on that machine. Bingo 99.99% (more) secure (than 99.99 of the other Bitcoin folks)

Ente

Well, this opsec scenario is to look at OS in isolation, with any possible ancillary config in mind!


But if you want specifics, I'm looking to keep this online for the medium term. Mostly as I've not got another PC to use for offline transaction signing. And choice of new hardware should be a whole thread to itself IMO, lots to consider as far as hardware goes (and reading what you're saying about hardware keyloggers, this includes keeping the machine in a locked safe or something to protect me from ninjas breaking in and bugging my IO devices!)

Sticking to where the OS meets hardware, am I right to think that exposure to closed source hardware drivers/HAL interfaces is an issue that depends 100% on what hardware you run with an OS with such closed source components? So, could a careful choice of hardware make Linux Libre unnecessary?

It all depends on what scenario you want to protect yourself from.

So, lets begin with: Offline or online? :-)

The larger and more popular the distro, the more binary stuff in it.
The smaller and obscure the distro, the more incentive for the devs to do something evil intentionally, and the less eyes looking for unintentional bugs.
(preparing for flamewar here)

Also, the less online, the less convenient.

And, to put all of this into perspective: It all won't help *anything* against a dedicated attacker: Hardware-keyloggers, softwarekeyloggers (installed while breaking into your home), tempest. Or, to render *all* technical solutions worthless: $5 wrench attack against you or your loved ones.

I enjoy playing through opsec scenarios. What's yours?

Ente

I'm looking at 2 models, but more than happy for people to suggest something else, too.

Something Unix based seems like a must, so....

1. Linux-Libre

Linux kernel, but with every single bit of proprietary code ("binary blobs" as the Libre people call them) removed, including 3rd party hardware drivers (and so this limits your hardware choice somewhat).

The rationale is that there's less unknown bugs to exploit, not that it's inherently more secure. It seems that some of the distro teams accept bitcoin donations, so they will almost certainly use their own OS with a bitcoin client of their choice.

2. Qubes OS

Modified Fedora distro that uses Xen virtualisation to segregate hardware and software components at the OS level. USB controller can be given it's own "secure" VM. The network hardware is in a separate VM by default, as is the ring 0 aspects of the kernel. Software is arranged in "zoned" para-virtualised VMs; a single template is used for them all, but you're using resources that are segregated into separate instances of user accounts so the use of one "zone" does not effect another. "Secure cut and paste" can be used between the zones. Disposable VM's can be used to open PDF files or to browse the web (i.e. a brand new VM is created from the para-virt template, then the VM and all activity within it is deleted upon closing the Disposable Application)

You're free to arrange the any number of add-on VM's that you like, dedicated to whatever hardware device or application. I'm thinking that something like that would be great to restrict to Armory use.


Am I taking this too seriously? Or should I consider thinking further outside the box, and trying FreeBSD, or thinking about the hardware first and the OS second? (I think hardware might need it's own thread, I've already come across plenty of interesting stuff in that area of research)