Bitmessage components security seclusion example

BM-2cWAGNFZQMxFERazCKZmQFGZ3x683rEq8e
Feb 16 01:05 [raw]

Real implementation would be a bit more complex, but this gives the general idea. Every part of the codebase that deals with privileged data is sandboxed by itself and can't communicate with the other parts of the codebase. Instead, each component runs a local server where direct sockets share information to cop functions, that filter it and either drop or forward to the other component's server. For instance, bitmessage has its API. In this regime, the cryptography would be a separate API - the inventory would be a separate API - the message storage would be a separate API. None of these APIs can connect to each other, because on startup random keys are generated for each API, and they can only connect to a parent function, the cop function, that filters every request, checks permissions, enforces security rules, and prevents malformed or maliciously transformed data from moving between APIs. Each API is cryptographically (socket keys) and systemically (OS, virtualenv, firefail) sandboxed to its domain, and can't break out. Ergo, your data can't break out. On top of this, the "secure station" idea proposed could separate some of these privileges to the other side of a serial port with hardware cops and code cops on both sides of the serial port. Until we have serial ports separating the components, functional walls and filters can be built between them. One could even use iptables and SELinux to further secure connections between APIs and their code cops. <br /> <br /> <img src="data:...">

[chan] Crypto-Anarchist Federation
BM-2cWdaAUTrGZ21RzCpsReCk8n86ghu2oY3v