cbcontrol(8)

📦 version 2.2, in fedora 43, fedora 44

✨ cbcontrol(8) ✨

okay so bestie, welcome to the cbcontrol man page, section 8, and honestly? it's giving backstage-pass-to-the-Crypto-Bone energy 👑

💖 NAME 💖

cbcontrol — literally the super-user sidekick that makes the Crypto Bone do stuff 💅

🌸 SYNOPSIS 🌸

cbcontrol  command [ args ]

🦋 DESCRIPTION 🦋

so here's the tea, bestie 🍓 cbcontrol is a process that runs under the super-user UID, and it gets commands from a GUI program called cryptobone2. when it gets those commands it does one of two things: either it relays them to an external Crypto Bone over an encrypted SSH link to a certain, fixed IP address, or it just... processes them itself, implementing a virtual Crypto Bone as a separate super-user process. and here's the iconic part — the commands for the virtual Crypto Bone and the external Crypto Bone are identical. no cap.

the GUI (which is running under the ordinary user UID, not the scary one) sends commands to this script via the sudo mechanism, and then cbcontrol executes these special commands using either the cryptobone daemon on the same machine (ALL-IN-ONE mode) or sends the commands to an external device (the cryptoboneexternd daemon) via a dedicated ssh tunnel (EXTERNAL mode). two modes, one queen 💖

the Crypto Bone software separates the user's GUI from the working of the "engine" — and that engine is the one taking care of encrypted message transport (via safewebdrop scripts) and decryption of incoming webdrop messages and attachment files, using and updating AES keys that are provided by the cryptobone daemon and stored in the database by the daemon. teamwork fr fr 🫶

and now the part that lowkey matters the most: all cleartext files (messages and attachments) live inside a ramdisk that can be accessed by the root user only. so the GUI has to send the appropriate commands via sudo to cbcontrol to have the task completed with access to the ramdisk that is inaccessible to everyone except the super-user root. that's the whole vibe check right there 🔥

🎀 COMMANDS 🎀

a command is executed only if the authentication with a local secret has been successful. this local secret is stored in the Linux file system.

the authentication information is provided by the program /usr/lib/cryptobone/getlocalsecret and it must match a stored hash of the local secret. if it doesn't match? the Crypto Bone does nothing. literally nothing. it just sits there 🙈

almost all commands make use of the encrypted data base of secrets, which is accessible only when the cryptobone daemon (/usr/lib/cryptobone/cryptoboned) has been started at boot time. the communication between the cryptobone daemon and cbcontrol is performed through a UNIX socket (as root).

these are the commands that can be sent to a Crypto Bone daemon through the UNIX socket:

  • USEALLINONE — switches to use of the ALL-IN-ONE mode. commands are executed by the software on the client machine that runs the GUI.
  • USECRYPTOBONE — switches to use the EXTERNAL device. commands are executed on an external device using a ssh tunnel to the external device with a dedicated IP address.
  • BONEIP — stores the IP address of the external device in the client machine in /usr/lib/cryptobone/cbb.config
  • GETALLINONE — reads the status of the Crypto Bone system.
  • DELETE — removes the stored IP address for an external device.
  • COPY_EXTERNAL_SECRETS — reads the secrets that have been generated by an external device into the client's database to enable the use of the GUI in EXTERNAL mode.
  • ATTACHMENT LIST — reads the list of attachment files that are present in the ramdisk.
  • ATTACHMENT COPY fileID — writes a copy of the attachment file into the user's home directory in $HOME/.safewebdrop

this is necessary to use the attachment file with the system's helper programs, because the user has no access to the ramdisk directly.

  • ATTACHMENT DELETE fileID — deletes the attachment file in the ramdisk.
  • DEBUG — shows the output of the command "systemd status cryptoboneexternd" on the external device for debugging purposes.
  • EXTERNAL STATUS — reads the status of the external device.
  • FETCH — starts the process of downloading safewebdrop messages and attachment files from the safewebdrop server. this is done automatically every 30 seconds while the GUI is in active use.
  • KEY USE safewebdropaddress initialsecret — resets a formerly used or new contact safewebdrop address to an initial value. this destroys all message keys currently in use for the contact safewebdrop address. the only way to continue the conversation is for the contact person to do a reset with the same initial secret for your own safewebdrop address, too. ⚠️ no going back on this one bestie.
  • KEY RECIPIENTLIST — provides a list of all registered safewebdrop addresses of contacts
  • MESSAGE COPY messageID — writes a copy of the message into the user's home directory in $HOME/.safewebdrop. the user is warned that copying reduces the protection on the message content, because the clear text message is no longer restricted to the ramdisk.
  • NETWORK STATUS CONNECT — shows the output of ifconfig for the ethernet adapter. applies to the external Crypto Bone only.
  • NETWORK STATUS FIREWALL — shows the status of the internal packet filter firewall. applies to the external Crypto Bone only.
  • NETWORK STATUS PING — checks the connection to a certain registered host on the internet to record connectivity information.
  • POWEROFF — performs a "shutdown -h now" on the external Crypto Bone. applies to the external Crypto Bone only. the virtual Crypto Bone uses SYSTEM POWEROFF to destroy all information in the local ramdisk.
  • REBOOT — performs a reboot on the external Crypto Bone. applies to the external Crypto Bone only.
  • READ DESTROY messageID — deletes the message from the list and deletes it in the ramdisk.
  • READ MESSAGELIST — writes a list of message names to stdout.
  • READ MESSAGE messageID — writes the specified base64-encoded message in plain text to stdout.
  • READ WEBDROPLIST — writes a list of original encrypted webdrop file names to stdout.
  • READ WEBDROP webdropID — writes the specified original encrypted webdrop text to stdout.
  • SETUP WID — writes the content of the user's safewebdrop user name to stdout.
  • SETUP WEBDROP — writes the current safewebdrop setup to stdout.
  • SETUP WEBDROPUSER username — sets the user name for a safewebdrop address that can be used to exchange encrypted messages.
  • SETUP WEBDROPSERVER servername — sets the safewebdrop server name where the username is registered as a valid user.
  • SETUP WEBDROPSECRET password — sets the password used to protect the RSA private key, which the safewebdrop transport needs to sign requests for the safewebdrop server. this information is stored in the database and can only be read by the super-user. 🔐
  • SETUP REGISTER — attempt a registration of WEBDROPUSER%WEBDROPSERVER at the safewebdrop server with the credentials stored in the database.
  • SETUP REGISTRATION — writes the registration code which was returned by the safewebdrop server to stdout.
  • STATUS — writes "active" to stdout if the masterkey is present or "waiting" if not.
  • SYSTEM SUSPEND — blocks the use of the encrypted secrets data base by renaming the masterkey. applies to the external Crypto Bone only.
  • SYSTEM RESUME — enables the use of the encrypted secrets data base, if the masterkey was suspended. applies to the external Crypto Bone only.
  • SYSTEM POWEROFF — destroys all information stored in the RAM disk. not used by the external Crypto Bone. it uses POWEROFF or REBOOT instead.
  • SYSTEM RESTART — initialises the ramdisk similar to the boot process of an external Crypto Bone. this command is used only by the virtual Crypto Bone.
  • WRITE safewebdrop_address base64string — starts the process of encrypting and sending the encrypted message (and attachment file) to the specified recipient's safewebdrop address after processing the base64-encoded plain text string. a message will only be sent out if a message key for the recipient's safewebdrop address is in the data base and if the message can be AES encrypted with this key successfully. two conditions, no shortcuts 💫

🌈 FILES 🌈

  • /usr/lib/cryptobone/cbcontrol
  • /usr/lib/cryptobone/cbcontrol.functions
  • /usr/lib/cryptobone/getlocalsecret
  • /usr/lib/cryptobone/secrets.sock
  • /usr/lib/cryptobone/ssh.sock
  • /usr/lib/cryptobone/database
  • /usr/lib/cryptobone/getlocalsecret
  • /usr/bin/cryptobone

(yes, /usr/lib/cryptobone/getlocalsecret really is listed twice — iconic behaviour, we don't gatekeep 💅)

⭐ SEE ALSO ⭐

  • cryptoboned (8)

👑 AUTHORS 👑

cbcontrol has been written by Ralf Senderek <innovation@senderek.ie>. slay.

💀 BUGS 💀

of course there aren't bugs, but if you find any, please sent them to innovation@senderek.ie. (that's the manpage's words, not mine — but bestie, if you do find one, you know where to send it 🙈)

and that's the whole page, babe 💜 this cbcontrol(8) goodness comes to you from Ralf Senderek, page cbcontrol(8) — go forth and control your Crypto Bone, main character energy only ✨🦋🌸

📦 where this page comes from