For those who dont know, bash history is the system that keeps track of the commands that you have hit in the past. you can see the on disk version with “cat ~/.bash_history”, and you can see the in-memory version with the “history” command, or by hitting up-arrow.
The Problem:
bash history on normal systems has a problem when using it, and qubes adds one more problem
- The problem that all systems have is that the history is stored in a ~/.bash_history file, but it’s written when bash exits. This means that you start your machine, and start running commands in 5 differnt terminals (with bash in each), then later close the terminals, and the last bash to exit overwrites all the changes of the other terminals.
This means when you later come back looking for your previous command, there is only a 1 in 5 chance that it is there. - When running qubes, instead of running 1 system with one ~/.bash_history file, users run a bunch of qubes, each with its own ~/.bash_history file. This means that hunting down a command that you did in the past can require searching the .bash_history file in all qubes.
A possible solution:
There is a program called Atuin that replaces your existing shell history with a SQLite database, and records additional context for your commands.
The additional context includes a session id number that tracks which bash process the command was run in.
(Note: atuin is already in debian trixie)
This can help solve problem #1.
Now for problem #2, the qubes fragmentation issue, atuin also provides a server that is intended to allow synchronization between computers. If this was turned into a qubes rpc service, then instead it would allow synchronization between qubes on a single machine.
The security implications
I’m asking about peoples thoughts on the security implications. For example, by opening a service with two way communication between the atuin server and every inidivudal qube, we have just opened up a potential inter-qube attack path. (attack and comprimize the atuin server, then attack every qube on the system).
Perhaps a better approach would be to set up audit logging on each qube, combined with with log aggregation (WORKING: Guide for creating a logging qube (I.E. sys-log) - WIP, or possibly the “journalctl” version discussed here: logvm(s) · Issue #830 · QubesOS/qubes-issues · GitHub), then parse the logs that are collected into a database?
I’m open to thoughts