
When I first learned about the
OSI model in my CCNA training, I didn't foresee how it could affect the face of privacy and anonymity. JanusVM, was my first big public project. What made it different from all the other implementations of anonymity and privacy software was the fact that it existed in a separate OSI model than the applications that would be using it. As a result of running in a Virtual Machine, it exist in a separate OSI model. In order for JanusVM to be able to communicate with other OSI models (computers), we choose to use a VPN to route all traffic to JanusVM from a remote or local computer.
All the advantages of this method were not apparent to Martin and I when we first built it. We just wanted Tor to be able to work with *any* TCP based application, since lots of applications do not support Socks proxy's. However, it quickly became obvious to us through user feedback that JanusVM could be used for more than just VPN. With one small change to JanusVM, it could be a router for an entire network. By being a router for other virtual or physical machines on a local network, we had achieved the lowest possible layer on the OSI model, Layer 1 or Physical Layer.
While it may not be obvious to most users of anonymity and privacy software, the OSI model is a corner stone of all telecommunications and technology that goes into your computer systems security. By having a layer of separation between the software you depend on for your anonymity (Tor) and the applications that use the anonymity software, you significantly reduce the surface area for 0-day attacks that can *completely* compromise your anonymity.
An example of this, that Martin and I found, was the ability for *any* web browser on *any* operating systems to be able send Tor commands through the ControlPort (if it was enabled). This had many negative affects on the clients anonymity, privacy, and security. Some of which include:
- Revealing the clients true IP address (anonymity).
- Mapping hidden services to the clients own computer (security)
- Mapping hidden services to other computers in the clients local network (security)
- Mapping hidden services to other services on the Internet (security)
- Moving the client from the public Tor network to a privately controlled Tor network (privacy)
This vulnerability, as with several others that have affected Tor's anonymity, had no affect on JanusVM because the OSI model was on our mind when we made it.
-- XEROBANK AND THE OSI MODEL --
So when it comes to xB Machine, I am trying to keep the same level of security through good design. I want xB Machine to be 0-day resistant just as JanusVM is. However, it is very difficult to separate each application from the operating system and still being able to access shared data in a secure manner. Good security and easy-to-use convenience generally do not go hand in hand.
As it stands right now with xB Machine, Tor and/or OpenVPN are running in the same OSI model as the applications that use it. The reason for this is memory. In the upcoming updates, each application will be running in a chjail(ed) environment to help prevent exploits from affecting any other part of the OS.
For the next major revision of xB Machine, I will be starting from scratch, square 1 if you will. The reason for this is that I came on board with xeroBank after xB Machine had already existed. Everything I have done to xB Machine was just a modification to an already existing image. In order to achieve our goal of being the world's most secure and easy-to-use operating system, it has to be done from square 1 with source and really good documentation.
I do have a personal version of xB Machine that has JanusVM running inside it, but that requires at least 512MB of RAM. To have a VM running inside a VM uses a lot more memory than what I'm comfortable with. It works, but I do not feel comfortable releasing it to the public as it is extremely alpha and not stable. Right now xB Machine requires 256MB of RAM to run well, and that is where I want to keep it if possible.