3 ms·
Some of my clients actually wanted to be able to make arbitrary queries in the database. And this isn't just about SQL queries. Often, people want to be able t
by EGreg 1y ago
Some of my clients actually wanted to be able to make arbitrary queries in the database.
And this isn't just about SQL queries. Often, people want to be able to make privileged changes to json config files, etc. etc.
So, I added a feature to the Qbix framework, to do just that. Essentially you have some privileged payloads, signed off by an Auditor role with their private key. You might even require M of N keys.
Then, for each Target (e.g. a database) you can use an ACL or Roles+Permissions for who can actually execute the payload against it.
This can be used on:
* Smart Contracts
* SQL Queries on Databases
* Upgrade Scripts on Nix machines
* Updates on package managers (versions that were vetted)
and much more.
Usually, when you have a bunch of "n00bs" who shouldn't be trusted with X, you want to set up a class of Auditors who sign off on the latest changes, and then a class of Admins who manage the roles, including Auditors and Users.
You don't need sys admins or dev ops. Just have standard container images / AMIs etc. and support only those. Don't even allow ssh into the instance, if you can help it. Let the instance be a pristine environment (Trusted Execution Environment) and discover arbitrary updates at well-known URLs, such as on github. You can have mirrors and fallbacks, but the key is that M of N Auditors from the organization's whitelist have signed off on the arbitrary code of any upgrade, whether delivered via a package manager or a git post-commit hook.
And all updates become automatic, and available to the n00bs to use. Role-based access is always enforced per-target when they attempt to use it. Inside the black box you can use simple HMAC to verify authorizations it issued earlier.
It took me a while to understand this, but the only way to solve security is to either have "pristine environments" that can run arbitrary code but always check M of N signatures for updates, with "byzantine fault tolerant consensus" on top. In the first one, you have to trust cloud providers. For the second one, you sacrifice some privacy. (e.g. with the new FreeNet's smart contracts).
PS: the M of N signatures might have to be hardened against quantum computers, so rather than using elliptic curve cryptography you might want to use lattice-based or my favorite quantum-resistant approach: SPHINCS+ based on Lamport signatures.