The only secure thing is Tor Tails booted from USB. Sent from my Android so do not expect a fast, long, or perfect response... On Sep 9, 2013 11:37 AM, "adrelanos" <adrela...@riseup.net> wrote:
> Speaking as a maintainer of Whonix... > > Before answering this, there is some prerequisite knowledge. There is a > difference between: > - Free Software and free software > - Open Source and open source > > When I am using capitalized Open Source, I am referring to OSI approved > [1] licenses (by the Open Source Initiative). When I am using > capitalized Free Software, I am referring to FSF approved [2] licenses > (by the Free Software Foundation). > > I try to prevent using the terms "open source" (which could refer to, > you can get the source code, perhaps for no charge) and free software. > The terminology is seriously messed up, but that's not my fault and no > one is listening to me. > > Praedor Atrebates: > > In light of the recent revelations of how the NSA has broken commercial > > software all over the place, I wonder about the security of Oracle's > > VirtualBox VM software used by Whonix (and other?) tor-based anonymity > > systems. > > We're probably all hosed anyway. Already for other reasons, backdoors in > plain source code. (I will address the concern of about being > non-opensource mail below.) Another reason is, when it comes to C and > C++ code, even in the source code you can add subtle, difficult to spot > backdoors. And I quote Ken Thompson: > > "The moral is obvious. You can't trust code that you did not totally > create yourself. (Especially code from companies that employ people like > me.) No amount of source-level verification or scrutiny will protect you > from using untrusted code. In demonstrating the possibility of this kind > of attack, I picked on the C compiler. I could have picked on any > program-handling program such as an assembler, a loader, or even > hardware microcode. As the level of program gets lower, these bugs will > be harder and harder to detect. A well installed microcode bug will be > almost impossible to detect." [3] > > Solution? > 1) Let's ditch decades of effort in writing C code. > 2) Create an operating system with minimal C code. > 3) Freeze the C code base. Only allow most critical changes. > 4) Re-implement all other software in higher level languages. Accept the > performance penalty or wait for faster hardware. > 5) Also somehow get trustworthy, backdoor-free hardware. [Really Hard (tm)] > I am not in position to suggest such changes. > > > A large portion of VirtualBox is open source but some > > libraries used are of different licenses...so perhaps somewhere in those > > non-opensource libs lay an NSA backdoor? > > To my knowledge, VirtualBox does not include portions where no source > code is available for download. > > VirtualBox is in Debian contrib, because it requires a non-free > (according to Debian DFSG [4] and FSF). > > The openwatcom compiler is considered non-free because it's under the > "Sybase Open Watcom Public License version 1.0". FSF says > > "This is not a free software license. It requires you to publish the > source code publicly whenever you “Deploy” the covered software, and > “Deploy” is defined to include many kinds of private use." [5] > > I think Debian also does not use openwatcom compiler, because that > compiler is not in Debian due to packaging difficulties. [6] > > According to the Debian VirtualBox license file [7], "Upstream provides > pre-built BIOS images which is used instead." > > There is also a VirtualBox bug report "Compiling BIOS requires Open > Watcom compiler" [8], which won't be fixed, but still contains > interesting information. It says, > > "By the way, we provide alternative sources (assembly) of the components > that normally get built with OpenWatcom, so VirtualBox can be built > without it. There is nothing missing, we even use them ourselves when > build the Solaris distribution of VirtualBox. For some reason this seems > not to be sufficient for all distros." [9] > > I don't know if the Debian VirtualBox license file refers to this > assembly. The thing Debian (rightly so) complains about might be, that > it's not nicely-commented and formatted assembly source code, but > assembly binary code? > > Anyhow. Realistically, lets assume it was nicely-commented and formatted > assembly source code. I like to refer back to what I wrote above subtle > backdoors in plain source code. > > Your concern is a valid one. For too long, the rumor, that Open Source > provides strong security and prevents backdoors has been spread. > > There is also just another issue. A non-deterministically build > operating systems. > > Open Source does not automagically prevent backdoors [12], unless the > user creates its own binaries from source code itself. The ones who > compile, upload and distribute (also the webhost) the binaries could add > a backdoor without publishing the backdoor code. Nothing prevents one to > claim, that a certain binary has been build from a clean source code, > while the binary was actually build by the source code plus the backdoor > code. Also the ones who may have infected the build machine with a > backdoor are in position to add a backdoor without the distributor being > aware of it. Deterministic builds can detect backdoors. For more > information on deterministic builds and why this is important, see: > - liberationtech mailing list: Deterministic builds and software trust [13] > - gitian.org [14] > - Quote Mike Perry: Current popular software development practices > simply cannot survive targeted attacks of the scale and scope that we > are seeing today. Source: Deterministic Builds Part One: Cyberwar and > Global Compromise [15] > - Debian wiki about their progress and development efforts to implement > Reproducible Builds [16] > > That's why I said, we're hosed anyway. Against an adversary with as much > resources as are available to the NSA, Open Source security is fatally > failing. > > > I'm wondering about any and all similar tor-based systems wherein there > > is ANY portion that is not opensource. > > Scrutiny is a good thing. I suggest using the vrms tool to find non-free > software. [10] [11] Parts of this non-free software may come without > source code being available. From a quick curious look into the Tails > source code greping for "nonfree", I found "firmware-linux-nonfree". > > There may be more good reasons to add such packages than against adding > such packages. (Because not adding those may result in such poor > hardware support, that there aren't enough users in the first place to > even theoretically provide anonymity.) > > The development version of Whonix (we'll probably make a new release > soon) includes a check using vrms (while building from source code), > which provides safety against installing non-free software. > > (Tails aiming to be run on hardware may not be so easily be able to drop > all non-free packages. It's much easier for Whonix when aiming at > Virtual Machines - I am not saying this solves the problem - it leaves > the user alone with the decision to install such non-free packages on > the host.) > > [1] http://opensource.org/licenses > [2] http://www.gnu.org/licenses/license-list.html > [3] http://cm.bell-labs.com/who/ken/trust.html > [4] https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines > [5] https://www.gnu.org/licenses/license-list.html#Watcom > [6] http://bugs.debian.org/376431 > [7] > > http://ftp-master.metadata.debian.org/changelogs//contrib/v/virtualbox/virtualbox_4.2.16-dfsg-2_copyright > [8] https://www.virtualbox.org/ticket/12011 > [9] https://www.virtualbox.org/ticket/12011#comment:3 > [10] http://packages.debian.org/vrms > [11] https://en.wikipedia.org/wiki/Vrms > [12] https://en.wikipedia.org/wiki/Backdoor_%28computing%29 > [13] > https://mailman.stanford.edu/pipermail/liberationtech/2013-June/009257.html > [14] http://gitian.org/ > [15] > > https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise > [16] https://wiki.debian.org/ReproducibleBuilds > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsusbscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk